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ABSTRACT 


This  Report  summarizes  recent  activities  in  the  Department 
of  Defense  and  in  the  US  Navy,  Army,  and  Air  Force  to  establish 
Service  use  of  Interactive  Electronic  Technical  Manuals  (IETMs) 
as  replacements  for  paper  Technical  Manuals  for  logistic 
support  of  military  equipment. 


The  IETM  concept  is  described,  and  an  overview  is  provided 
of  five  IETM  acquisition  Specifications  and  Military  Handbooks 
developed  by  the  Tri-Service  Interactive  Electronic  Technical 
Manual  Working  Group  established  in  1989  by  the  Defense  Quality 
and  Standardization  Office. 


One  of  these  five  draft  documents,  MIL-D-IETMDB ,  Revisable 
Data  Base  for  Support  of  Interactive  Electronic  Technical 
Manuals  (IETMs),  1  Jun  1990,  is  described  and  presented.  (Four 
other  companion  Reports  have  been  prepared  to  introduce  and 
describe  the  four  related  IETM  acquisition  Specifications  and 
Handbooks . ) 


This  Report  introduces  the  concept  of  the  Revisable  IETM 
Data  Base,  which  serves  as  the  basis  for  the  construction  of 
View  Packages  and  as  a  source  of  other  system-related  logistic- 
support  Technical  Information  required  b>  various  IETM  users  in 
a  number  of  different  activities  throughout  each  Service.  The 
primary  constituents  of  the  Data  Base  are  described: 

(1)  the  Data  Entities,  which  constitute  the  technical 

data  contained  in  the  IETMDB; 

(2)  the  "Attributes",  which  provide  relevant  technical 

data  concerning  the  Data  Entities;  and 

(3)  the  "Relationships"  which  provide  the  linkages  among 

the  Data  Entities  of  the  IETMDB. 

Required  data  access  and  data  interchange  features  of  the 
IETMDB  are  summarized,  and  the  functions  which  the  Data  Base 
must  support  are  enumerated. 


A  copy  of  MIL-D-IETMDB  is  included  in  this  Report  as  an 
Appendix. 
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1.0  INTRODUCTION 


1 . 1  BACKGROUND 

During  the  1980s,  it  became  increasingly  apparent  that  the 
striking  increases  in  the  complexity  and  sophistication  of  the 
weapon  systems  of  all  three  Services  were  causing  a  serious  lag 
in  the  production,  distribution,  and  management  of  the 
Technical  Information  required  to  maintain,  operate,  and 
support  these  systems.  Of  particular  concern  were  increasing 
weight  and  space  requirements  resulting  from  the  increasing 
bulk  of  the  required  paper  Technical  Manuals. 


At  the  same  time,  a  number  of  significant  technological 
improvements  were  being  made  in  the  field  of  information 
handling,  particularly  the  advent  of  small,  inexpensive,  fast 
computers.  Such  innovations  offered  the  potential  of  almost 
complete  replacement  of  paper-based  Technical  Information 
through  the  use  of  light,  easily  stored,  highly  capable 
electronically  processible  media,  which  at  the  same  time  were 
capable  of  more  effective  interactive  display  to  the  end  user. 


Research,  Development,  Test,  and  Evaluation  efforts  of  the 
three  Services  during  this  past  decade  have  conclusively 
demonstrated,  both  through  field  tests  and  through  in-house 
analyses  and  experimentation,  the  feasibility  and  intrinsic 
value  of  providing  integrated  Technical  Information  in 
paperless  form  in  such  a  way  that  it  can  be  displayed  to  end 
users  by  means  of  an  interactive  Electronic  Display  System. 
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For  example,  the  Navy  Technical  Information  Presentation 
System  (NTIPS)  Program  at  David  Taylor  Research  Center,  the 
Navy  'i  Lead  Laboratory  for  TI  automation,  demonstrated  under 
operational  conditions  the  improvements  achievable  in 
maintenance-technician  performance  [Refs  (1)  and  (2) ]  through 
the  use  of  electronically  displayed  TI.  Similar  results  have 
been  achieved  by  the  Air  Force  under  its  Computer-based 
Maintenance  Aiding  Information  System  (CMAS)  and  its  Integrated 
Maintenance  Information  System  (IMIS)  programs 
[Refs  (3)  and  (4)].  The  Army  has  automated  Training 
Information  under  its  Electronic  Information  Delivery  System 
(EIDS) ,  and  has  assessed  the  capability  of  using  field  portable 
maintenance  aids  under  the  Militarized  Electronic  Information 
Delivery  System  (MEIDS)  program. 


In  addition,  a  number  of  pilot  prototype  developments  and 
tests  involving  land,  sea,  and  air  vehicles  and  their  weapon 
systems  are  being  carried  out,  by  individual  System  Acquisition 
Managers  of  all  three  Services,  in  an  effort  to  provide 
interactive  and  electronically  displayed  Technical  Information. 


Ref  (1)  Fuller,  Joseph  J.,  Theodore  J.  Post,  and  Anne  S.  Mavor,  "Test 
and  Evaluation  of  the  Navy  Technical  Information  Presentation 
System  (NTIPS),  F-14A  Field  Test  Results,"  DTRC-88/036  (Sep  1988). 

Ref  (2)  Fuller,  Joseph  J.,  Raymond  L.  LeBeau,  Anne  S.  Mavor,  Theodore 
J.  Post,  and  Charles  S.  Sawyer,  "Test  and  Evaluation  of  The  Navy 
Technical  Information  Presentation  System  (NTIPS),  AN/SPA-25D  Test 
Results,"  DTRC-88/035  (Sep  1988). 

Ref  (3)  Thomas,  D.L.  and  J.D.  Clay,  "Computer-Based  Maintenance  Aids  for 
Technicians:  Project  Final  Report,"  Air  Force  Human  Resources 

Laboratory,  AFHRL-TR-87-44  (Aug  1988). 

Ref  (4)  Link,  W.R.,  J.C.  Von  Holle,  and  D.  Mason,  "Integrated 
Maintenance  Information  System  (IMIS):  A  Maintenance  Information 
Delivery  Concept,"  Air  Force  Human  Resources  Laboratory, 
AFHRL-TP-87-2 7  (Nov  1987). 
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1.2  DOD  AND  TRI-SERVICE  PROGRAMS  ESTABLISHED  IN  RESPONSE  TO 

TECHNICAL  INFORMATION  AUTOMATION  POLICY 

To  coordinate  and  standardize  the  increased  use  of 
computer-aided  logistic  support  throughout  the  three  Services, 
the  Department  of  Defense  established  the  Computer-aided 
Acquisition  and  Logistics  Support  (CALS)  program  [see  Ref  (5)], 
which  also  has  had  a  wide  effect  in  stimulating  progress  toward 
the  goal  of  TI  automation,  and  particularly  toward 
standardization  of  such  efforts. 


The  Department  of  Defense  established  [Ref  (5)],  and 
later  reiterated  [Ref  (6)],  a  policy  requiring  that  access  to 
and  the  delivery  of  system-related  logistic-support  information 
be  automated. 


For  example,  Ref  (6)  provided  the  following  directions: 

a.  For  systems  now  in  full-scale  development  or 
production,  program  managers  were  required  to  review 
specific  opportunities  for  cost  savings  or  quality 
improvements  that  could  result  from  changing  delivery 
or  access  using  the  Computer-aided  Acquisition  and 
Logistics  Support  standards. 

b.  For  systems  entering  development  after  September  1988, 
acquisition  plans,  solicitations,  and  related  documents 


Ref  (5)  DEPSECDEF  MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS, 
of  24  Sep  1985.  Sub j :  Computer  Aided  Logistic  Support. 

Ref  (6)  DEPSECDEF  MEMORANDUM  FOR  SECRETARIES  OF  THE  MILITARY  DEPARTMENTS 
AND  DIRECTOR,  DEFENSE  LOGISTICS  AGENCY,  of  5  Aug  1988.  Sub j : 
Computer-Aided  Acquisition  and  Logistic  Support. 
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required  specific  schedule  and  cost  proposals  for: 

(1)  integration  of  Contractor  Technical  Information 
systems  and  processes; 

(2)  authorized  Government  access  to  Contractor  data 
bases;  and 

(3)  delivery  of  Technical  Information  in  digital  form. 

c.  DOD  components  were  to  program  for  automated  systems  to 
receive,  store,  distribute,  and  use  digital  weapon- 
system  Technical  Information,  including  achieving  the 
earliest  possible  date  for  digital  input  to  DOD 
engineering  data  repositories. 


More  recently,  the  Joint  Uniform  Service  Technical 
Information  System  (JUSTIS)  concept  has  been  announced,  a 
planned  effort  which  will  combine,  to  as  great  a  degree  as 
possible,  Tri-Service  procedures  and  equipment  for  acquisition 
and  control  of  system-support  Technical  Information. 


1.3  THE  INTERACTIVE  ELECTRONIC  TECHNICAL  MANUAL  CONCEPT 

The  culmination  of  this  effort  throughout  the  1980s  in 
response  to  the  DOD  policy  statements  cited  has  been  the 
development  of  the  Interactive  Electronic  Technical  Manual 
(IETM)  Concept.  The  IETM  Concept  involves  full  application  of 
existing  technological  capabilities  to  the  problems  of 
providing  Technical  Information  which  is  both  more  effective 
for  the  end  user  and  more  efficient  in  terms  of  acquisition, 
control,  and  update. 
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The  IETM  Concept  involves  a  system  approach,  which 
includes  basically  all  of  the  following  components: 

a.  A  standardized,  automated,  revisable  source  Data  Base. 

b.  Use  of  a  computer-controlled  authoring  system. 

c.  The  generation  of  digital  Technical  Information 
(containing  text  and  graphics) ,  either  directly  by  an 
Author,  or  automatically  by  computer.  This  Technical 
Information  is  recorded  on  an  electronically 
processible  medium  (optical  or  magnetic) ,  rather  than 
on  paper. 

d.  Technical  Information  (consisting  of  task-related 
increments)  which  is  optimally  arranged  and  formatted 
for  interactive  screen  presentation. 

e.  Presentation  (display  to  the  end  user)  by  means  of  a 
computer-controlled  Electronic  Display  System  (EDS) 
possessing  an  extensive  user-interaction  capability. 
The  EDS  is  capable  of  displaying  the  IETM,  performing 
related  logistic-support  functions,  and  interfacing 
with  other  Service  logistic-support  Information 
Systems . 

An  IETM  permits  a  user  to  locate  required  information  more 
easily,  and  to  present  it  faster,  more  comprehensibly,  more 
specifically  matched  to  the  configuration,  and  in  a  form  that 
requires  much  less  storage  than  paper.  Powerful 

troubleshooting  procedures  not  possible  with  paper  Technical 
Manuals  are  possible  using  the  computational  capability  of  the 
IETM  Display  Device. 
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IETMs  will  be  used  by  maintenance  technicians,  afloat  and 
ashore;  to  maintain  and  operate  weapon  systems  by  Intermediate 
and  Depot  maintenance  activities;  and  by  training  personnel. 


The  IETM  Concept  has  been  described  in  detail  in  Ref  (7) . 


1.4  PREPARATION  OF  SPECIFICATIONS  AND  HANDBOOKS  FOR  SERVICE¬ 
WIDE  COORDINATION  OF  ACQUISITION  OF  AUTOMATED  TECHNICAL 
INFORMATION 


To  coordinate  this  wide-spread  effort,  the  Defense  Quality 
and  Standardization  Office  established  in  1989,  under  the  DOD 
Technical  Manual  Technology  Exchange  Subcommittee,  chartered  by 
DOD  INST  4151.9  [Ref  (8)],  an  Interactive  Electronic  Technical 
Manual  Working  Group,  chaired  by  the  Navy,  whose  primary 
functions  were  to: 

a.  Foster  the  exchange  of  ideas  and  the  agreement  on  a 
single  approach  regarding: 

(1)  the  acquisition  of  IETMs  which  use  computer 
technology  for  innovative  electronic  display;  and 

(2)  presentation  of  Technical  Manual  Information  among 
all  Department  of  Defense  Agencies. 


Ref  (7)  Rainey,  Samuel  C. ,  Joseph  J.  Fuller,  and  Eric  L.  Jorgensen, 
"The  Electronic  Delivery  of  Automated  Technical  Information  for 
Logistics  Support  of  Navy  Weapons  Systems:  Potential,  System 

Description,  and  Status,"  DTRC-89/007  (Feb  1989). 

Ref  (8)  DoD  Instruction  4151.9  of  3  Jan  1989,  "DoD  Technical  Manual  Program 
Management . " 
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b.  Develop  a  set  of  DOD  Specifications  for: 


(1)  The  acquisition  of  IETM  data;  and 

(2)  The  Electronic  Display  Systems  needed  for  the 
presentation  of  IETMs  for  the  maintenance  of  DOD 
weapons,  systems,  and  equipment. 


The  Working  Group  was  also  charged  with  the  responsibility 
of  providing  a  recommendation  to  the  DOD  CALS  Policy  Office 
concerning  inclusion  of  IETM  interchange  Specif ications  into 
the  set  of  CALS  standards;  e.g.,  in  connection  with 
MIL-STD-1840. 


The  Tri-Service  Working  Group  consists  of  representatives 
of  (a)  the  David  Taylor  Research  Center  (DTRC)  of  the  Navy, 
(b)  the  Air  Force  Logistics  Command  (AFLC-MMDE) ,  and  (c)  the 
US  Army  Communications-Electronics  Command  (AMCPM-TMDE) . 


With  DTRC  and  the  Air  Force  Human  Resources  Laboratory  (as 
an  advisor  to  AFLC)  contributing  the  primary  effort,  a  series 
of  five  Specifications  (see  Section  2.3)  and  Handbooks  for  IETM 
acquisition  has  been  drafted.  This  series  consists  of: 

■  A  Specification  governing  the  nature  of  the  Revisable 
IETM  Data  Base; 


■  A  Specification  providing  general  Content,  Style, 
Format,  and  User-Interaction  Requirements  for  all  IETMs; 

■  A  Handbook  describing  for  a  System  Acquisition  Manager 
the  best  approach  to  writing  acquisition  Specifications 
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for  individual  View  Packages  (to  be  used  for  IETM 
procurement) ; 

■  A  Handbook  presenting  requirements  for  the  Electronic 
Display  System; 

■  A  specification  presenting  requirements  for  an  IETM 
Quality  Assurance  Program. 


These  documents  have  been  widely  circulated  for  comment 
within  both  the  DOD  and  Industry. 


These  drafts  were  also  developed  to  accomplish  as  a  near- 
term  objective  the  provision  of  a  suite^of  IETM  prototype 
acquisition  documents  for  use  by  major  DOD  programs  in 
establishing  initial  IETM  capabilities.  These  programs  include 
the  Navy's  A-12  Attack  Aircraft  Program,  the  Advanced  Tactical 
Fighter  Program  of  the  Air  Force,  and  the  M-l  Main  Battle  Tank 
Program  of  the  Army. 


1.5  PURPOSE  OF  PRESENT  REPORT 


The  purpose  of  the  present  Report  is  to  present  and  to 
describe  in  detail  one  of  these  draft  documents,  specifically: 
Draft  Military  Specification:  MIL-D-IETMDB. 

Revisable  Data  Base  for  Support  of  Interactive 
Electronic  Technical  Manuals  (IETMs) .  1  June  1990. 
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A  series  of  four  other  Reports  has  been  prepared,  each 
Report  describing  one  member  of  the  set  of  five  acquisition 
documents  prepared  by  this  Working  Group  [Ref  (9)  through 
Ref  (12)]. 


Section  2  of  this  Report  provides  an  overall  description 
of  this  suite  of  Acquisition  Specifications  and  Handbooks. 
Section  3  summarizes  the  Approach  and  Requirements  of  one  of 
the  five  documents;  in  this  case,  MIL-D-IETMDB.  The  draft 
version  of  MIL-D-IETMDB  is  included  in  this  Report  as 
Appendix  A. 


Ref  (9) 


Ref  (10) 


Ref  (11) 


Ref  (12) 


Rainey,  Samuel  C. ,  Eric  L.  Jorgensen,  and  Joseph  J.  Fuller, 
"Proposed  Draft  Military  Handbook  for  Preparation  of  View 
Packages  in  Support  of  Interactive  Electronic  Technical 
Manuals,"  DTRC  Report  90/026  (Jul  1990). 

Rainey,  Samuel  C.,  Eric  L.  Jorgensen,  and  Joseph  J.  Fuller, 
"Proposed  Draft  Military  Specification  for  Quality  Assurance 
(QA)  Program  Requirements  for  Interactive  Electronic  Technical 
Manuals  ( IETMs ) , "  DTRC  Report  90/024  (Jul  1990). 

Jorgensen,  Eric  L.,  Samuel  C.  Rainey,  and  Joseph  J.  Fuller, 
"Proposed  Draft  Military  Handbook  Presenting  Requirements  for 
an  Electronic  Display  System  for  Interactive  Electronic 
Technical  Manuals  (IETMs),"  DTRC  Report  90/025  (Jul  1990). 

Jorgensen,  Eric  L. ,  Samuel  C.  Rainey,  and  Joseph  J.  Fuller, 
"Proposed  Draft  Military  Specification  for  General  Content, 
Style,  Format,  and  User-Interaction  Requirements  for 
Interactive  Electronic  Technical  Manuals  (IETMs)," 
DTRC  Report  90/028  (Jul  1990). 
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2.0  ACQUISITION  DOCUMENTATION  FOR 
INTERACTIVE  ELECTRONIC  TECHNICAL  MANUALS 
AND  ASSOCIATED  TECHNICAL  INFORMATION 


2 . 1  DEFINITIONS 


2.1.1  The  Interactive  Electronic  Technical  Manual  (IETM) . 

As  defined  by  the  Working  Group,  an  IETM  is  a  Technical 
Manual,  prepared  (authored)  by  a  Contractor  and  delivered  to 
the  Government,  or  prepared  by  a  Government  activity,  in 
digital  form  on  a  suitable  medium,  by  means  of  an  automated 
authoring  system;  designed  for  electronic-screen  display  to  an 
end  user;  and  possessing  the  following  three  characteristics: 

a.  The  format  and  style  of  the  presented  information  are 
optimized  for  screen  presentation  to  assure  maximum 
comprehension;  that  is,  the  presentation  format  is 
"frame-oriented”,  not  "page-oriented". 

b.  The  elements  of  Technical  Information  constituting  the  TM 
are  so  interrelated  that  a  user's  access  to  the 
information  he  requires  is  facilitated  to  the  greatest 
extent  possible,  and  is  achievable  by  a  variety  of  paths. 

c.  The  computer-controlled  TM-Display  Device  can  function 
interactively  (as  a  result  of  user  requests  and 
information  input)  in  providing  procedural  guidance, 
navigational  directions,  and  supplemental  information;  and 
also  in  providing  assistance  in  carrying  out  logistic- 
support  functions  supplemental  to  maintenance. 
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This  terminology  is  consistent  with  the  standard  DOD 
definition  of  Technical  Manual.  Ref  (8),  states: 

Technical  Manuals  are  publications  that  contain  instructions  for  the 
installation,  operation,  maintenance,  training,  and  support  of  weapon 
systems,  weapon-system  components,  and  support  equipment.  TM 
information  may  be  presented  in  any  form  or  characteristic,  including  but 
not  limited  to  hard  printed  copy,  audio  and  visual  displays,  magnetic  tape, 
discs,  and  other  electronic  devices.  They  normally  include  operational  and 
maintenance  instructions,  parts  lists  or  parts  breakdowns,  and  related 
technical  information  or  procedures  exclusive  of  administrative 
procedures.  Technical  Orders  (TOs)  that  meet  the  criteria  of  this 
definition  may  also  be  classified  as  TMs. 


2.1.2  The  View  Package. 

IETM  information,  as  provided  to  the  end  user  for  viewing 
on  an  Electronic  Display  Device,  will  be  constructed  in 
individual  task-oriented  increments  called  View  Packages. 


A  View  Package  (VP)  is  a  fully  organized  and  formatted 
item  of  computer-process ible  Technical  Information  derived  from 
an  IETM  Data  Base  and  capable  of  interactive  electronic  display 
to  an  end  user  by  means  of  an  Electronic  Display  System  (EDS) . 
In  function  and  design,  a  View  Package  is  completely  equivalent 
to  an  individual  Interactive  Electronic  Technical  Manual.  A 
View  Package  may  be  constructed: 

a.  entirely  by  an  Author  using  an  automated  authoring 
system; 
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b.  completely  automatically  using  a  series  of  automated 
processes  (software)  which  perform  the  data-selection, 
structuring,  and  formatting  processes;  or 

c.  by  a  combination  of  the  above  two  approaches. 


A  View  Package  is  designed  to  support  a  specific  function 
in  the  operation  or  logistics-support  of  a  weapon  system  or 
other  military  equipment. 


2.1.3  Nature  and  Purpose  of  the  Revisable  IETM  Data  Base 

As  noted  above,  a  View  Package  is  created  entirely  from 
data  contained  in  a  Revisable  IETM  Data  Base  (IETMDB)  ,  which  is 
a  complete  collection  of  Data  Elements  relating  to  a  weapon 
system  or  other  equipment  acquired  by  the  Government  and 
constructed  in  a  standardized  procedure  in  order  to  provide  the 
following  capabilities: 

a.  Government  activities  or  DOD  Contractors  concerned 
with  logistic  support  for  the  weapon  system  involved 
can  access  the  Data  Base  directly  to  obtain  needed 
logistic-support  information  for  specific  purposes. 

b.  The  IETMDB  can  serve  as  the  basis  for  construction 
and  update  of  the  entire  suite  of  electronically 
displayed  interactive  weapon-system  Technical 
Manuals  through  the  use  of  automated  authoring 
systems . 

c.  The  IETMDB  can  serve  as  the  basis  for  fully 
automated  construction,  by  either  a  Contractor  or  a 
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Government  Activity,  of  View  Packages,  which  are 
increments  of  interactive  electronically  presented 
logistic-support  Technical  Information. 

d.  Required  portions  of  the  IETMDB  can  be  interchanged 
by  means  of  standardized  procedures  throughout  the 
DOD  and  its  supporting  Contractors  on  a  real-time 
basis  when  needed. 


2.1.4  The  Electronic  Display  System  (EDS) 

The  EDS  is  a  computer-based  Technical  Information  system 
designed  to  accept,  process  and  integrate  Technical  Information 
for  prime-equipment  logistics  support,  and  display  that 
information  to  users.  The  EDS  is  also  intended  to  support 
inquiries  by  users  (in  addition  to  Operations  and  Maintenance 
users)  who  have  such  responsibilities  as  supply,  training, 
field-data  collection,  readiness  measurement,  operations 
scheduling,  maintenance  planning,  maintenance  quality  control, 
and  hardware  configuration  control.  The  software  supporting 
the  EDS  will  also  be  required  to  support  additional  (as  yet 
unspecified)  functions  in  the  future,  which  will  emerge  as 
technologies  and  standards  evolve.  Specifically,  the  EDS 
is  intended  for  use: 

a.  In  maintenance  Work  Centers  and  shops  to  support 
Troubleshooting  and  Planned  and  Corrective 
Maintenance; 

b.  In  portable  form  at  remotely  located  maintenance 
sites ; 
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c.  Embedded  in  a  weapon-system  control  panel  as  support 
both  for  System  operation  and  System  maintenance; 

d.  In  presenting  operating  and  maintenance  information 
during  personnel  training  courses; 

e.  In  a  variety  of  centers  and  offices  in  support  of 
System-related,  logistics-supported  functions  which 
require  Technical  information. 


The  Electronic  Display  System  will  consist  of  one  or 
more  computer-controlled  Devices  which  display  the  required 
Technical  Information  by  means  of  a  screen  (such  as  a  cathode- 
ray-tube  or  a  plasma  display)  either  in  a  pre-ordered  sequence 
or  in  random-access  increments,  as  called  for  by  the  user; 
e.g.,  a  maintenance  technician.  To  accomplish  this  display, 
the  IETM,  consisting  of  the  Technical  Information  recorded  on 
a  suitable  medium  (e.g.,  on  an  optical  disc) ,  is  designed  to  be 
loaded  into  the  EDS,  "read"  by  this  Device,  and  displayed  in  a 
sequence  as  directed  by  the  user. 


The  IETMs  to  be  used  by  this  Display  System  must 
accordingly  be  so  constructed  as  to  assure  full  compatibility 
with  the  operating  software  of  the  Display  Device,  and  must  be 
tested  by  the  preparing  Contractor  on  such  a  Display  Device 
prior  to  delivery. 


2.1.5  Summary 

As  noted,  all  IETMs: 
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a.  Will  be  constructed  through  the  use  of  an  automated 
authoring  system,  and  will  consist  of  task-related 
increments  referred  to  as  View  Packages; 

b.  Will  be  based  on  an  automated  system  Data  Base,  the 
IETMDB,  prepared  by  the  System  Prime  Contractor  for 
delivery  as  such  to  the  Government,  retention  for  his 
own  use,  or  both; 

c.  Will  consist  of  a  digital  data  stream  recorded  on  an 
optical  or  magnetic  medium,  but  not  paper, 
electronically  displayed  by  the  Electronic  Display 
System  in  terms  of  text  and  graphics; 

d.  Will  be  optimally  formatted  and  styled  for  screen 
presentation  (i.e.  ,  "frame  oriented"  rather  than  "paper 
oriented") . 

e.  Will  be  constructed  for  electronic  display  on  a  highly 
interactive  Electronic  Display  System,  which  will 
support  related  logistic-support  functions  and  which 
may  be  networked  for  interface  with  other  Service 
Information  Management  Systems. 


2.2  IETM  PROCUREMENT  OPTIONS 

Logistic- support  procedures  for  weapon  systems  and  related 
equipment  differ  to  some  extent  among  the  Services.  A  certain 
amount  of  necessary  variation  in  the  acquisition  procedures 
involving  the  VPs,  the  IETMDB,  and  the  EDS  has  been  provided  in 
the  system  of  Specifications  and  Acquisition  Handbooks 
developed  by  the  IETM  Working  Group. 
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Thus,  these  Specifications  and  Handbooks  detail  several 
optional  approaches  in  the  acquisition  of  lETMs .  These  are  as 
follows: 


a.  Using  appropriate  IETM  Specifications,  the  Service 
may  buy  whatever  directly-authored  Interactive 
Electronic  Technical  Manuals  are  required.  Although 
the  Author  (equipment  Prime  Contractor)  will!  need  to 
establish  an  automated  equipment  or  weapon-system 
(source)  Data  Base,  this  Data  Base  will  not  be  acquired 
by  the  Government,  but  will  be  maintained  and  used  by 
the  Contractor,  both  for  the  preparation  of  IETMs  and 
for  other  purposes. 

(1)  As  an  option,  the  Government  might  contract  for 
on-line  access  to  technical  portions  of  this 
Contractor-owned  Data  Base.  In  such  a  case,  both 
content  and  accessibility  aspects  of  the  IETM  Data 
Base  would  have  to  be  constructed  to  standard 
requirements . 


b.  Acquisition  by  the  Government  of  directly  authored 
IETMs  (fully  prepared  and  validated  by  the  Contractor) 
as  well  as  the  IETM  Data  Base  upon  which  they  are 
based.  Government  acquisition  of  the  IETM  Data  Base 
may  involve  either  of  the  following  options: 

(1)  Delivery  to  the  Government  in  standardized  form 
and  subsequent  maintenance  by  the  Government  (with 
or  without  update  information  supplied  on  a 
continuing  basis  by  the  Contractor) ; 

(2)  Title  acquired  to  the  IETM  Data  Base  by  the 
Government,  but  with  the  Data  Base  retained  and 
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maintained  in  the  Contractor's  plant.  The 
Government  to  be  provided  with  on-line  access  to 
the  Data  Base. 


c.  Based  on  acquisition  of  the  IETM  Data  Base,  using 
either  option  b. (1)  or  b.(2),  preparation  of  View 
Packages  using  either  a  fully  automated  process  or  one 
which  is  essentially  fully  automated.  View  Packages 
could  be  prepared  either: 

(1)  By  the  Contractor  [based  on  Data-Base  acquisition 
option  b.(l)],  and  delivered  as  such  to  the 
Government,  or 

(2)  By  the  Government  [based  on  Data-Base  acquisition 
option  b. (2) ] . 


2.3  SUMMARY  AND  PURPOSE  OF  THE  DRAFT  ACQUISITION 
SPECIFICATIONS  AND  HANDBOOKS  PREPARED  BY 
THE  TRI-SERVICE  IETM  WORKING  GROUP 

As  noted,  five  draft  Specifications  and  Handbooks  have 
been  prepared,  and  circulated  widely  for  DOD  and  Industry 
comment,  to  provide  System  Acquisition  Managers  with  the 
necessary  contractual  documentation  for  acquisition  of 
Interactive  Electronic  Technical  Manuals,  the  associated  Data 
Base,  and  the  necessary  Electronic  Display  Systems.  These 
statements  of  requirements  are  preliminary  and  will  certainly 
be  modified  as  experience  is  gained  with  the  acquisition, 
management,  and  use  of  this  type  of  Technical  Information,  as 
the  technology  advances,  and  as  the  Department  of  Defense 
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improves  its  in-house  logistic-support  infrastructure  for 
support  of  IETMs. 


The  five  draft  Specifications  and  Handbooks  prepared  by 
the  Inter-Service  IETM  Working  Group  (of  which  Appendix  A  of 
this  Report  is  one) ,  together  with  individual  statements  of  the 
purpose  of  each  document,  are  as  follows: 


2.3.1  The  Revisable  IETM  Data  Base  Specification 


2. 3. 1.1  Title 

Draft  MIL-D-IETMDB.  Revisable  Data  Base  for  Support  of 
Interactive  Electronic  Technical  Manuals  (IETMs) . 
1  June  1990. 


2 . 3 . 1. 2  Purpose 

This  Specification  contains  the  requirements  for  a 
Revisable  Interactive  Electronic  Technical  Manual  Data  Base 
(IETMDB)  to  be  constructed  by  a  weapon-system  Contractor.  This 
non-redundant  and  neutrally  formatted  Data  Base  is  intended  to 
be  the  single  source  of  data  for  all  Technical  Manuals  to  be 
used  in  support  of  a  given  weapon  system,  or  other  equipment 
being  acquired  by  the  Government.  This  Specification  may  be 
used  in  two  primary  modes: 

a.  as  a  set  of  standard  requirements  to  which  the 
Contractor  must  adhere  in  the  development  and 
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maintenance  of  his  internal  Data  Base  for  subsequent 
conversion  to  Government-deliverable  form;  and 

b.  as  a  set  of  requirements  for  a  Data  Base  that  is 
physically  delivered  to  the  Government,  or  is 
maintained  by  the  Contractor  on  behalf  of  the 
Government. 


2.3.2  The  IETM  General  Content.  Style.  Format,  and  User- 
Interaction  Requirements  Specification 


2. 3. 2.1  Title 


Draft  MIL-M-GCSFUI .  Manuals ,  Interactive  Electronic 
Technical:  General  Content,  Style,  Format,  and  User- 
Interaction  Requirements  for.  1  June  1990. 

2 . 3 . 2 . 2  Purpose 

This  Specification  contains  common  requirements  for  the 
Content,  Style,  Format,  and  User-Interaction  features  required 
for  Interactive  Electronic  Technical  Manuals  and  the  operating 
software  of  the  devices  upon  which  they  are  viewed.  These 
IETMs  are  to  be  delivered  to  the  Government  in  digital  form  and 
must  be  designed  for  interactive  display  to  the  maintenance- 
technician  end-user  by  means  of  a  computer-controlled 
Electronic  Display  System.  The  range  of  IETMs  for  which 
general  requirements  are  described  in  this  Specification  will 
cover  the  maintenance,  diagnostic,  training,  system-operation, 
parts-information,  and  installation  functions  which  are 
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required  to  achieve  and  maintain  full  operational  capability  of 
a  specific  weapon  system  or  other  military  equipment. 


2.3.3  The  IETM  View  Package  Handbook 

2. 3. 3.1  Title 

Draft  MIL-HDBK-IETMVP.  Guidelines  for  Developing 
Specifications  for  Interactive  Electronic  Technical 
Manual  (IETM)  View  Packages.  1  June  1990. 

2 . 3 . 3 . 2  Purpose 

The  purpose  of  this  Handbook  is  to  provide  guidance  for 
the  preparation  of  individual  View-Package  Specifications,  so 
that  System  Acquisition  Managers  may  define  View  Package 
Requirements  quickly  and  effectively  for  the  numerous  different 
specialized  increments  of  Technical  Information  which  will  be 
required.  A  Handbook  of  this  type  has  been  referred  to  as  a 
meta-specification:  a  Specification  describing  how  to  write  a 
View  Package  specification  which  is  the  end-item  specification 
for  procurement  of  an  actual  IETM. 


2.3.4  The  IETM  OA  Program  Requirements  Specification 
2 . 3 . 4 . 1  Title 

Draft  MIL-M-IETMQA .  Quality  Assurance  ( QA )  Program 
Requirements  for  Interactive  Electronic  Technical 
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Manuals  (IETMs)  and  Associated  Technical  Information. 

1  June  1990. 

2. 3. 4. 2  Purpose 

This  Specification  prescribes  the  requirements  for  a 
Contractor's  QA  program  for  Interactive  Electronic  Technical 
Manuals  (IETMs)  and,  where  procured,  the  associated  IETM  Data 
Bases  and  supporting  View  Packages.  The  requirements  herein 
cover  the  QA  process  and  present  the  plan  for  implementing  it, 
from  planning  through  final  submission  of  the  delivered  product 
for  acceptance;  they  apply  as  well  to  changes  and  revisions 
thereto. 


2.3.5  The  Electronic  Display  System  Handbook 

2. 3. 5.1  Title 

Draft  MIL-HDBK-EDS  (Navy) .  Electronic  Display  System 
(EDS)  for  Interactive  Electronic  Technical  Manuals 
(IETMs).  1  June  1990. 

2 . 3 . 5 . 2  Purpose 

This  Handbook  describes  the  basic  functional  requirements 
for  an  Electronic  Display  System  (EDS)  designed  to  display 
Interactive  Electronic  Technical  Manuals  (IETMs) .  It 
establishes  the  minimum  system  requirements  to  be  used  in  a 
detailed  Specification  for  competitive  procurement,  either  for 
portions  of  the  full  requirements  or  tailored  to  suit  the 
application,  user  environment,  device  compatibility,  and 
interfaces  to  existing  computer  systems. 
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The  requirements  described  in  this  Handbook  are  of  three 
types : 

a.  Those  which  describe  the  Electronic  Display  System 
hardware ; 

b.  Those  which  describe  the  EDS  software  of  the  display 
System  for  system  operation,  IETM  applications,  and 
utility  functions. 

c.  Those  which  specify  the  minimum  performance  of  the 
several  individual  Display  Devices  which  constitute 
the  EDS. 


To  achieve  full  compatibility  of  the  EDS  with  the  IETMs 
and  View  Packages,  the  Display  System  Software  (as  well  as  the 
View  Package)  must  also  be  constructed  in  compliance  with 
MIL-M-GCSFUI . 


Each  of  the  three  Services  has  its  own  strategies  for 
developing  Specifications  and  Standards  for  an  Electronic 
Display  System.  This  Handbook  presents  the  existing  Navy 
concepts,  and  is  accordingly  identified  as  a  Navy-only 
document.  Proposed  concepts  of  the  other  Services  which  do  not 
differ  extensively  from  requirements  described  in  this  Handbook 
will  be  included  in  succeeding  versions  of  the  Handbook. 


2.4  RELATIONSHIP  OF  MIL-D-IETMDB  TO  OVERALL  SET  OF 
IETM- ACQUISITION  SPECIFICATIONS  AND  HANDBOOKS 

The  IETM  concept  requires  that  all  Technical  Information 
required  for  the  IETM  Technical  Information  increments  referred 
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to  as  View  Packages  be  extracted  from  among  the  set  of  Data 
Entities  contained  in  a  single,  revisable  source  Data  Base 
prepared  by  the  equipment  Prime  Contractor.  Custody  of,  and 
direct  access  to,  this  Data  Base  may  or  may  not  be  acquired  by 
the  Government  for  its  own  use  in  preparing  View  Packages  (and 
for  other  purposes) . 


In  order  to  permit  System  Acquisition  Managers  to  make 
greatest  use  of  this  IETM  Data  Base,  the  Specification 
MIL-D-IETMDB  has  been  prepared  to  assure  that,  when 
contractually  applied:  (1)  its  content  is  complete  and 
relevant,  and  (2)  its  accessibility  and  transferability 
characteristics  are  compatible  with  standardized  DOD 
procedures.  QA  procedures  described  in  MIL-M-IETMQA  are  to  be 
applied  to  the  IETM  Data  Base,  and  Data  Entities  in  the  IETMDB 
are  to  be  accessible  by  the  automated  VP  extraction  routines 
described  in  MIL-HDBK-IETMVP. 


3.0  SUMMARY  OF  MILITARY  SPECIFICATION  MIL-D-IETMDB 
Revisable  Data  Base  for  Support  of 
Interactive  Electronic  Technical  Manuals  (IETMs) 

1  June  1990 


3.1  PURPOSE  OF  MIL-D-IETMDB 

As  noted  in  Section  1.3  of  this  Report,  the  IETM  concept 
includes  the  provision  that  IETMs  will  be  prepared  from  a 
standard  comprehensive  revisable  source  Data  Base  which 
contains  all  of  the  Technical  Information  required  for  logistic 
support  of  a  given  weapon  system  or  other  military  equipment. 
This  Data  Base  will  be  created  and  maintained  by  the  equipment 
Prime  Contractor.  The  process  of  creating  View  Packages 
involves  extraction,  structuring,  formatting,  and  adding  User- 
Interaction  features  to  this  Technical  Information. 


As  procurement  options,  the  Government  may: 

a.  physically  acquire  this  Data  Base; 

b.  acquire  ownership  of  the  Data  Base  and  leave  it  fully 
under  maintenance  and  control  of  the  Contractor;  or 

c.  acquire  full  or  partial  access  to  the  Data  Base  without 
ownership . 

To  permit  any  of  these  three  options,  it  has  been  necessary  to 
establish  requirements  concerning  the  content,  access,  and 
transferability  features  of  the  Data  Base,  so  that  Government 
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Activities  can  interact  with  it  in  a  standardized  way. 
MIL-D-IETMDB  has  been  prepared  to  serve  this  purpose. 


Except  for  the  content,  accessibility,  and 
interchangeability  aspects  of  the  IETMDB,  the  Specification 
does  not  specify  the  nature  or  construction  (format)  of  the 
Data  Base.  MIL-D-IETMDB  includes  four  Appendices  which  provide 
satisfactory  examples  of  IETM  Data  Bases  using  differing 
approaches  to  construction  and  to  tagging. 


For  an  equipment  procurement  whereby  a  series  of  View 
Packages  is  also  acquired,  but  the  IETM  Data  Base  is  not 
acquired,  the  Contractor  may  nevertheless  find  it  expedient  to 
design  his  Data  Base  in  accordance  with  MIL-D-IETMDB  in  case 
the  Government  may  later  decide  to  procure  it  or  in  case 
automated  data  interchange  becomes  necessary  among  a  group  of 
activities  involved  with  logistics  aspects  of  the  military 
equipment  involved. 


3.2  NATURE  OF  THE  IETMDB 

The  IETMDB  is  basically  a  collection  of  Data  Entities. 
Each  of  these  Entities  is  named  and  described  in  a  Data  Element 
Dictionary  (DED) .  A  detailed  example  of  a  draft  DED  is  given 
as  Appendix  A  to  MIL-D-IETMDB. 


3.2.1  Data  Entities 

Data  Entities  constitute  the  entire  technical  data  base 
and  are  of  numerous  types  (all  identified  by  the  DED)  .  For 
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example,  a  Data  Entity  with  the  standard  name  EQUIP  identifies 
the  equipment  needed  to  perform  a  particular  Task  or  Step. 
There  may  be  many  instances  in  the  IETMDB  of  the  EQUIP  Data 
Entity,  each  identifying  one  of  many  types  of  equipment  needed 
for  specific  purposes.  Data  Entities  may  be  "primitive"  (e.g., 
a  single  graphic  or  line  of  text)  or  "composite"  (a  linked 
sequence  of  text,  graphics,  or  text-graphics  combinations) . 


3.2.2  Data-Entitv  Attributes 

As  noted  in  Section  3.1.2  of  MIL-D-IETMDB,  each  Data 
Entity  is  associated  with  one  or  more  "Attributes",  also 
identified  in  the  Data  Element  Dictionary  which  describes  the 
IETMDB.  (See  Section  3  of  Appendix  A.)  An  Attribute  (of  a 
Data  Entity)  is  an  item  of  data  which  represents  any  property 
or  characteristic  of  the  Data  Entity  considered  useful.  As  an 
example:  For  a  given  instance  of  a  piece  of  equipment  cited 
under  a  Data  Entity  named  EQUIP,  an  Attribute  might  be  the  MTBF 
[Mean  Time  Between  Failures]  of  that  piece  of  equipment.  Such 
an  Attribute  may  be  called  a  Descriptive  Attribute.  Another 
class  of  Attributes  consists  of  "Contextual  Attributes",  which 
define  the  context  for  the  use  of  the  Data  Entities  to  which 
these  Attributes  apply  (e.g.,  an  Attribute  stating  that 
Organizational  Maintenance  is  the  context  for  the  use  of  a 
given  piece  of  test  equipment) . 


3.2.3  Data  Entity  Relationships 

The  IETMDB  also  incorporates  lists  of  "Relationships" 
which  provide  links  among  Data  Entities.  For  example,  an 
instance  of  a  specific  equipment  under  EQUIP  may  be  linked  to 
one  or  more  Entities  identified  by  the  name  TASK,  STEP,  or 
ALTEQUID  (alternative  equipment  which  will  fulfill  the  same 
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function) .  All  of  these  Relationships  must  be  identified  in 
the  IETMDB  Data  Element  Dictionary. 


3.3  REQUIRED  FEATURES  OF  THE  IETMDB 

MIL-D-IETMDB  requires  that  the  IETM  Data  Base: 

a.  Fulfill  the  functions  of  providing  the  basis  (source 
information)  for  constructing  View  Packages,  both  by 
direct  authorship  and  by  fully  automated  (algorithmic) 
procedures . 

b.  Provide  access  to  a  variety  of  logistics-support  users 
for  a  wide  range  of  purposes  (these  will,  in  general, 
be  specified  during  a  procurement) . 

c.  Be  capable  of  straightforward  revision. 

d.  Conform  closely  to  the  Logistic  Support  Analysis  Record 
(LSAR) . 

e.  Be  Validated  as  a  part  of  the  Contractor's  Quality 
Assurance  Program. 

f.  Be  supplemented  by  a  Data  Element  Dictionary  (which  is 
to  be  available  on-line  to  users) . 

g.  Be  put  into  standard  form  for  delivery  to  the 
Government  (when  the  acquisition  option  is  exercised) . 

h.  Contain  clear,  unambiguous  System  applicability 
statements  for  all  Data  Entities  contained.  (This 
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Requirement  must  be  closely  coordinated  with  the  data¬ 
base  revision  function.) 

i.  Provision  of  data  supporting  both  "expert"  and  "novice" 
levels  (tracks)  when  this  option  is  exercised  (Section 
3.3.1  of  MIL-D-IETMDB) . 


3.4  IETM  DATA  BASE  EXAMPLES  PROVIDED  BY  MIL-D-IETMDB 


As  noted,  the  IETMDB  may  be  constructed  (formatted)  in  a 
variety  of  ways  -  for  example,  either  as  an  object-oriented  or 
as  a  relational  Data  Base  -  so  long  as  they  are  in  conformance 
with  the  requirements  of  the  Specification.  To  illustrate  this 
variation  in  permitted  construction,  summaries  of  four 
approaches  are  appended  to  the  Specification  as  follows: 


APPENDIX  B:  Description  of  an  IETM  Data  Base  in  IDEF1X 
representation . 

APPENDIX  C:  EXPRESS  Presentation  of  an  IETM  Data  Base. 

APPENDIX  D:  A  NIAM  [Nijssen  Information  Analysis 
Methodology]  Representation  of  an  IETM  Data 
Base. 


APPENDIX  E:  CDM  [Content  Data  Model]  version  of  an  IETM 
Data  Base,  prepared  as  an  SGML  [Standard 
Generalized  Markup  Language]  Document  Type 
Definition  [DTD]  (an  AFHRL  Working  Draft, 
Version  5.2). 
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APPENDIX  A 


Copy  of  Draft  Military  Specif ication: 


MIL-D-IETMDB 

Revisal)le  Data  Base  for  Support  of 
Interactive  Electronic  Technical  Manuals  (IETMs) 

1  June  1990 


Prior  to  the  publication  of  this  report  the  document 
included  as  Appendix  A  has  been  officially  submitted  to  the 
DOD  Defense  Quality  Standardization  Office  and  the  DOD  CALS 
Policy  Office  by  the  Office  of  the  Chief  of  Naval  Operations, 
Code  403  -  Logistics  Policy  (OPNAV  LTR  4160  Ser  403T/OU593187 
dtd  4  Jun  1990) .  It  has  also  been  submitted  to  the  Pageless 
Technical  Manual  Working  Group  of  the  Aerospace  Industry 
Association  for  Review  and  Comment.  This  document  was 
distributed  as  a  review  draft  and  is  largely  a  DTRC  product 
with  assistance  from  the  Air  Force  as  noted.  This  Appendix 
is  in  the  exact  form  that  was  submitted  to  these 
organizations . 
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MIL-M-IETMDB 
1  June  1990 


NOTE:  This  review  draft,  dated  1  June  1990,  has  been  prepared  by 

DTRC/AFHRL/LRC  for  purposes  of  technical  review  and  comment  by  Industry 
and  DOD  organizations.  It  has  not  been  approved  and  is  subject  to 
modification.  DO  NOT  USE  FOR  ACQUISITION  PURPOSES. 


*  *  *  *REVIEW  DRAFT**** 

Beneficial  comments  (recommendations,  additions,  deletions)  and 
any  pertinent  data  which  may  be  of  use  in  improving  this 
document  should  be  addressed  to:  David  Taylor  Research  Center, 
Code  182.3,  Bethesda,  Maryland  20084-5000. 
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MILITARY  SPECIFICATION 


REVI SABLE  DATA  BASE  FOR  SUPPORT  OF 
INTERACTIVE  ELECTRONIC  TECHNICAL  MANUALS  ( IETMs ) 


l .  SCOPE 


This  Specification  contains  the  requirements  for  a  Revisable 
Interactive  Electronic  Technical  Manual  Data  Base  (IETMDB)  to  be 
constructed  by  a  weapon-system  Contractor.  This  Data  Base  is  intended 
to  be  an  integrated  source  of  data  for  all  Technical  Manuals  to  be  used 
in  support  of  a  given  system,  to  be  delivered  to  the  Government.  This 
Specification  may  be  used  in  two  primary  modes:  (1)  as  a  set  of 
standard  requirements  to  which  the  Contractor  must  adhere  in  the 
development  and  maintenance  of  his  internal  data  base  for  subsequent 
conversion  to  Government-deliverable  form;  and  (2)  as  a  set  of 
requirements  for  a  data  base  that  is  physically  delivered  to  the 
Government,  or  is  maintained  by  the  Contractor  on  behalf  of  the 
Government . 

1 . 1  Introduction 

1.1.1  Nature  and  Purpose  of  the  Revisable  Source  Data 

For  complex  weapon  systems  and  other  types  of  military  equipment, 
adequate  logistic  support  in  all  its  forms  requires  an  enormous  amount 
of  current,  readily  accessible,  accurate,  and 

highly  detailed  data,  consisting  of  Technical  Information  which  can  be 
displayed  electronically  to  an  end  user  in  both  textual  and  graphics 
form. 


The  concept  that  the  three  Services  can  either  acquire  and  maintain 
large-scale  data  bases  of  this  type,  or  acquire  access  to  such  data 
bases,  maintained  continuously  by  a  Contractor,  is  an  integral  part  of 
the  Interactive  Electronic  Technical  Manual  (IETM)  concept. 


A  Revisable  IETM  Data  Base  (IETMDB)  is  a  complete  collection 
of  Data  Entities  relating  to  a  weapon  system  or  other  equipment  acquired 
by  the  Government  and  constructed  in  a  standardized  procedure  in  order 
to  provide  the  following  capabilities: 

A.  Government  activities  or  DOD  Contractors  concerned  with 
logistic  support  for  the  weapon  system  involved  can 
access  the  Data  Base  directly  to  obtain  needed  logistic- 
support  information  for  specific  purposes. 

B.  The  IETMDB  can  serve  as  the  basis  for  construction  and 
update  of  the  entire  suite  of  weapon-system 
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electronically  displayed  interactive  Technical  Manuals 
through  the  use  of  automated  authoring  systems . 

C.  The  IETMDB  can  serve  as  the  basis  for  fully  automated 
construction,  by  either  a  Contractor  or  a  Government 
Activity,  of  View  Packages,  which  are  increments  of 
interactive  electronically  presented  logistic-support 
Technical  Information. 

D.  Required  portions  of  the  IETMDB  can  be  interchanged  by 
means  of  standardized  procedures  throughout  the  DOD  and 
its  supporting  Contractors  on  a  real-time  basis  when 
needed. 


1.1.2  Technical  Information  Procurement  Options 

Acquisition  of  Technical  Information  to  provide  operational  or 
logistic  support  of  military  equipment  may  be  carried  out  by  one  of 
several  optional  approaches.  These  are  as  follows: 


a.  Using  appropriate  IETM  Specifications,  buy  whatever  directly- 

authored  Interactive  Electronic  Technical  Manuals  are  required. 
Although  the  Author  (equipment  Prime  Contractor)  shall  need  to 
establish  an  automated  equipment  or  weapon-system  (source)  data 
base,  this  data  base  shall  not  be  acquired  by  the  Government,  but 
shall  be  maintained  and  used  by  the  Contractor,  both  for  the 
preparation  of  IETMs  and  for  other  purposes. 

1.  As  an  option,  the  Government  might  contract  for  on-line 
access  to  technical  portions  of  this  Contractor-owned  Data 
Base.  In  such  a  case,  both  content  and  accessibility  aspects 
of  the  IETM  Data  Base  would  have  to  be  constructed  to 
standard  requirements . 


b.  Acquisition  of  directly  authored  IETMs  (fully  prepared  and 

validated  by  the  Contractor)  as  well  as  the  IETM  Data  Base  upon 
which  they  are  based.  Acquisition  of  the  IETM  Data  Base  may 
involve  either  of  the  following  options: 

1.  Delivery  to  the  Government  in  standardized  form  and 
subsequent  maintenance  by  the  Government  (with  or  without 
update  information  supplied  on  a  continuing  basis  by  the 
Contractor) ; 

2.  Title  acquired  to  the  IETM  Data  Base  by  the  Government,  but 
with  the  Data  Base  retained  and  maintained  in  the 
Contractor's  plant.  The  Government  to  be  provided  with  on¬ 
line  access  to  the  Data  Base. 
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c.  Based  on  acquisition  of  the  IETM  Data  Base,  using  either  option 
II. A  or  II. B,  preparation  of  View  Packages  using  either  a  fully 
automated  process  or  one  which  is  essentially  fully  automated. 
View  Packages  could  be  prepared  either: 

A.  By  the  Contractor  (based  on  Data-Base  acquisition  option 
II. A),  and  delivered  as  such  to  the  Government,  or 

B.  By  the  Government  (based  on  Data-Base  acquisition  option 
II. B) 


This  Specification  provides  requirements  for  a  standardized  Revisable 
IETM  Data  Base  which  shall  permit  the  Government  to  acquire  Technical 
Information  by  applying  contractual  options  I,  II,  and  III. 


1.1.3  Scope  and  Limitations  of  this  Specification 

This  Specification  is  directed  primarily  toward  four  aspects  of  the 
IETMDB. 


(1)  The  Data  Base  Content  (through  provision  of  a  Data-Element 
Dictionary;  see  Appendix  A  of  this  Specification). 

(2)  Provisions  which  affect  access  to  any  part  (Data  Entities  or 
Data-Entity  sequences)  of  the  IETM. 

(3)  Provisions  which  permit  construction  of  View  Packages  through 
fully  automated  processes,  with  the  IETMDB  used  as  the  single 
source  of  Technical  Information.  In  constructing  a  View  Package, 
computer  programs  must: 

(a)  Extract  selected  Data  Entities  from  the  IETMDB. 

(b)  Compose  these  Data  Entities  into  coherent  form  and  organize 
the  View  Package. 

(c)  Apply  Format,  Style,  and  User-Interaction  Requirements  to 
the  View  Package  to  assure  comprehensible  interactive 
display  to  an  end  user  on  an  Electronic  Display  System. 

(4)  Provisions  which  affect  interchangeability  of  the  Data  Base,  or 
portions  of  it,  to  the  Government,  among  Government  Activities, 
and  among  Government  Contractors  involved  in  logistic  or 
manufacturing  support  of  the  system  involved.  This  area  of 
requirements  shall  require  standard  Data-Element  Tagging. 

Aspects  of  the  IETMDB  not  directly  or  indirectly  affecting  the 
above  four  areas  are  left  to  the  discretion  of  the  Contractor. 
Appendixes  B  through  E  of  this  Specification  provide  samples  of 
four  different  formulations  of  an  IETMDB,  which  may  be  used  for 
guidance . 
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1.2  Revisable  Format-Free  Technical  Information 

The  IETMDB  shall  consist  of  an  assemblage  of  Data  Entities,  including 
a  listing  of  Attributes  possessed  by  the  Data  Elements;  and  a  list  of 
explicit  Relationships  providing  logical  links  among  the  Data  Entities. 
The  Relationships  incorporated  into  the  Data  Base  by  the  IETMDB  Author 
provide  the  basis  of  the  technical  structure  of  the  IETMs ,  View 
Packages,  and  other  logistic-support  Technical  Information  which  shall 
be  extracted  from  it.  The  IETMDB  shall  not,  however,  contain  Format 
directions  in  the  sense  of  arrangement  of  text  and  graphics  on  a  display 
screen  for  presentation  to  the  end  user. 

The  IETMDB  itself  shall,  of  course,  require  a  "format"  (data-base 
structure)  but,  except  for  the  limitations  imposed  by  the  requirements 
outlined  in  Section  1.1.3,  this  Specification  does  not  impose  structural 
requirements  on  the  actual  Data  Base  Management  System  (DBMS) 
methodology  (e.g.,  the  Data  Base  may  be  either  relational  or  object- 
oriented:  see  Appendixes).  The  Input/Output  functions  must  conform  to 
requirements  of  this  Specification. 


1.2.1  Data  Portability 

The  "format-free"  nature  of  the  IETMDB  is  intended  to  provide  the 
Government  with  the  capability  to: 

a.  Acquire  or  access  the  Data  in  a  variety  of  ways  (IETMs,  View 
Packages,  and  many  other  types  of  reports;  training  TI); 

b.  Format  and  Style  the  Data  in  a  variety  of  ways  for  Electronic 
Display  Options; 


Elimination  of  formatting  requirements  for  the  IETMDB  also  reduces  the 
overall  magnitude  of  Data-Base  and  Data-Interchange  standardization 
effort,  and  permits  use  of  a  less  complex  DBMS  by  the  Contractor  which 
is,  in  turn,  less  expensive  and  easier  to  modify. 


1.2.2  Data  Maintainability 

Data  maintainability  shall  involve  changes  to  the  IETMDB  of  the 
following  two  kinds: 

a.  Additions  or  eliminations  of,  or  changes  to,  individual  Data 
Entities  (including  Attributes); 

b.  Changes  to  Relationships  (establishment  of  new  Relationships, 
elimination  of  old  Relationships). 
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To  accommodate  either  type  of  change,  the  IETMDB  must  be  constructed 
so  that  incorporation  of  the  change  automatically  updates  all  aspects  of 
the  Data  Base  affected  by  that  change. 


1.2.3  Integration  Support 

Since  one  of  the  functions  of  the  IETMDB  is  to  provide  direct  on-line 
data  access  to  a  variety  of  users  and  to  a  number  of  automated  logistic- 
support  and  management-information  systems  throughout  the  Services, 
establishment  of  identifiers  (key  words),  Data-Entity  relationships,  and 
multiple-path  access  routes  to  individual  Data  Entities  is  an  important 
part  of  IETMDB  design  and  construction. 


2  .  APPLICABLE  DOCUMENTS 


The  following  documents  of  issue  in  effect  on  the  date  of 
invitation  for  bid  or  request  for  proposal  form  part  of  this 
Specification  to  the  extent  specified  herein.  Specification  and 
Standard  issues  shall  be  those  listed  in  that  issue  of  the  Department  of 
Defense  Index  of  Specifications  and  Standards  (DODISS)  specified  in  the 
applicable  contract. 


2 . 1  Government  Documents 


2.1.1  Specifications  and  Standards 


2. 1.1.1  Specifications 


MIL-D-28003  Digital  Representation  for  Communication  of 
Illustration  Data:  CGM  Application  Profile 

MIL-Q-9858  Quality  Program  Requirements. 

MIL-M-GCSFUI  Manual,  Interactive  Electronic  Technical:  General 

Content,  Style,  Format,  and  User- Interaction  Requirements 
for 


MIL-M- IETMQA  Quality  Assurance  (QA)  Program  Requirements  for 

Interactive  Electronic  Technical  Manuals  (IETMs)  and 
Associated  Technical  Information. 
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2. 1.1. 2  Standards 

MIL-STD-1388-2B  DoD  Requirements  for  a  Logistics  Support  Analysis 
MIL-STD- 184 0A  Automated  Interchange  of  Technical  Information 
DOD-STD-2167  Defense  System  Software  Development 
DOD-STD-2168  Defense  System  Software  Quality  Program 

2.1.2  Other  Government  Documents 

MIL-HDBK-IETMVP  Preparation  of  view  Packages  in  Support  of 

Interactive  Electronic  Technical  Manuals 

MIL-HDBK-EDS  Electronic  Display  System  for  Interactive  Electronic 

Technical  Manuals. 


2.2  Other  Documents 


2 . 3  Order  of  Precedence 


In  the  event  of  a  conflict  between  the  text  of  this  Specification  and 
the  references  cited  herein,  the  text  of  this  Specification  shall  take 
preference. 
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3.  REQUIREMENTS 


3.1  General  Characteristics  of  Revisable,  Format-Free  Technical 
Information 


Technical  Information  contained  in  the  IETMDB  shall  be  in  the  form  of 
Data  Entities  (Section  3.1.1),  associated  with  Attributes  (Section 

3.1.2)  and  Relationships  (linkages  to  other  Data  Entities,  Section 

3.1.3) .  Such  Technical  Information  may  be  contained  within  a  variety  of 
DBMS  structures,  but  with  standardized  access  and  output  features.  The 
Technical  Information  contained  in  an  IETMDB  is  not  associated  with 
display  Format  or  Style  information. 


3.1.1  Content  of  Individual  Data  Entities 

The  Data  Entities  contained  in  the  IETMDB  consist  primarily  of: 

(1)  primitive  Data  Entities  (text,  graphics,  tables,  video  sequences, 
prompts /dialogues,  software  processes); 

(2)  composite  Data  Entities,  including 

(a)  composite  system-information  Entities, 

(b)  composite  descriptive-information  Entities, 

(c)  composite  troubleshooting-information  Entities  (fault- 
information,  test,  outcome),  and 

(d)  composite  parts-information  Entities. 

(e)  composite  graphic  Entities 

3.1.2  Data-Entitv  Attributes 


Data-Entities  have  "Attributes"  which  describe  their  content 
(Descriptive  Attributes),  or  which  define  the  context  for  their  use 
(Contextual  Attributes),  or  any  other  Attributes  considered  desirable 
due  to  the  special  nature  of  certain  Data  Entities. 


3.1.2. 1  Descriptive  Attributes 

Data  Entities  when  appropriate  shall  be  associated  with  the  three 
Descriptive  Attributes  (name,  item  identification,  and  information  type) 
which  describe  the  nature  of  that  Entity's  information  content.  All  the 
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Technical  Information  in  a  View  Package,  or  other  subsidiary  item  of  TI 
derived  from  the  IETMDB,  shall  be  indexed  by  these  three  Attributes. 


3 . 1 . 2 . 1 ■ 1  Name 


The  name  of  the  Data  Entity  shall  consist  of  the  standard  nomenclature 
for  the  Data  Entity.  For  instance,  the  name  might  be  the  standard 
nomenclature  for  a  weapon-system  component  if  the  Entity  is  a  system- 
information  Entity,  or  it  might  be  a  procedure  title  if  the  Entity 
consists  of  a  task  description. 


3. 1.2. 1.2  Item  Identification 


The  Item-Identification  Attribute  shall  specify  the  reference 
designator(s)  and  other  identifiable  designator ( s )  of  the  system(s), 
subassemblies,  or  part(s)  referred  to  by  the  Data  Entity,  based  on  the 
appropriate  MIL-STD-Number . 


3. 1.2. 1.3  Information  Type 

The  Information-Type  Attribute  further  specifies  the  type  of 
information  contained  in  the  Data  Entity.  For  example,  an  Entity 
consisting  of  a  procedural  task  statement  may  have  the  types:  adjust, 
align,  calibrate,  checkout,  clean  disassemble,  assemble,  inspect, 
lubricate,  operate,  remove,  install,  repair,  or  service.  An  Entity 
consisting  of  a  descriptive  statement  may  have  the  types:  equipment 
description,  theory  of  operation,  how-to-use-this-Manual .  A  graphic 
Entity  may  have  the  types:  locator  diagram,  functional  block  diagram, 
schematic,  wiring  diagram,  flow  diagram,  or  graph/chart. 


3. 1.2. 2  Contextual  Attributes 


Data  Entities  shall  be  associated  with  Contextual  Attributes  which 
define  the  situations,  or  "contexts",  in  which  the  Data  Entity  is 
appropriate  for  use. 

Contextual  Attributes  are  applied  in  a  manner  similar  to  that 
involving  Precondition  Entities  (see  Section  3. 2. 7.7).  The  information 
associated  with  a  given  Data  Entity  is  appropriate  only  if  the  context 
of  the  user's  situation  matches  the  set  of  Contextual  Attributes.  Thus, 
two  versions  of  the  same  task  may  exist,  with  different  Contextual 
Attributes . 


The  following  Sections  contain  examples  of  such  Attributes: 
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3. 1.2. 2.1  Security-Classification  Attributes 


The  Security  Attributes  shall  define  the  highest  level  of  security 
covered  by  the  Data  Entity's  contents. 


3. 1.2. 2. 2  System  Configuration  and  Effectivitv 

The  System-Configuration  Attribute  shall  contain  the  list  of  the 
system  configurations,  or  model  numbers,  to  which  the  Data  Entity 
applies . 


3. 1.2. 2. 3  Maintenance  Level 


The  Maintenance-Level  Attribute  shall  contain  a  list  of  the 
maintenance  levels  (e.g.  organizational,  intermediate,  depot)  to  which 
the  Data  Entity  applies. 


3. 1.2. 2. 4  Level  of  Detail  (Track) 

The  Level-of-Detail  Attribute  (track),  when  more  than  one  track  is 
specified  in  the  Contract,  shall  contain  a  value  of  "expert",  "novice", 
or  "all",  which  indicates  the  user-skill  level  appropriate  for  the  Data 
Entity.  For  this  purpose,  "expert"  and  "novice”  do  not  represent  any 
specific  military  task,  rank,  or  job  qualification,  but  rather  a 
relative  indication  of  how  familiar  the  individual  is  with  the  procedure 
or  information  being  described.  Information  at  the  "novice"  level  of 
detail  is  written  for  the  technician  with  very  little  recent  experience 
with  the  particular  maintenance  task  being  described.  Information  at 
the  "expert"  level  is  written  for  the  technician  who  frequently  performs 
the  task  and  does  not  need  elementary  explanations.  The  "expert"  track 
shall  always  include  all  warnings,  cautions,  and  safety-critical 
information  which  applies  to  the  maintenance  activity  being  described. 


3. 1.2. 2. 5  Document  Version 


The  Document-Version  Attribute  shall  contain  a  decimal  number  (e.g., 
1.0,  1.1,  2.0)  indicating  the  appropriate  document  version  of  the  Data 
Entity. 


3. 1.2. 2. 6  Validation  and  Verification  Status 

The  Validation-Status  and  Verification-Status  Attributes  shall 
indicate  the  Data-Entity  Validation  status  (either  validated  or 
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unvalidated)  and  the  Verification  status  (either  verified  or 
unverified),  respectively. 


3. 1.2. 2. 7  Author-Defined  Preconditions 

In  addition  to  the  built-in  Contextual  Attributes  described  above,  the 
Author  may  define  additional  precondition  properties  which  must  be 
satisfied  for  the  Data  Entity  to  be  applicable  to  the  current  context. 


3. 1.2. 3  Other  Attributes 


Individual  Data  Entities  may  have  additional  Attributes  which  define 
special  or  unique  characteristics  of  that  Data-Entity  type. 


3.1.3  Relationships  between  Individual  Data  Entities 

Entities  have  relationships  to  other  entities  in  the  technical 
information  database.  For  example:  (A  task  entity  has  a  list  of  step 
entities.  A  step  entity  may  have  a  list  of  warning  entities.  A 
troubleshooting  test  entity  shall  have  an  outcome  entity. )  These 
relationships  shall  be  explicitly  identified  in  the  database.  This 
identification  ensures  that,  when  one  part  of  the  technical  information 
changes,  all  affected  information  is  identified.  These  relationships 
also  make  it  easy  for  a  presentation  program  to  navigate  through  the 
data  to  find  required,  cross-referenced  information. 


3.2  Technical  Information  Data  Entities 


Data  Entities  of  the  IETMDB  may  be  classed  as  primitive  or  composite, 
or  in  terms  of  the  type  of  Technical  Information  contained  by  the  Data 
Entity.  The  following  Sections  describe  required  types  of  Data 
Entities . 


3.2.1  Item/Svstem  Hierarchy 

The  vehicle,  weapon  system,  or  other  equipment  that  is  being 
maintained  and  operated,  is  composed  of  several  layers  of  subsystems, 
components,  and  parts.  This  hierarchical  decomposition  of  the  equipment 
being  maintained  and  operated  is  accomplished  by  use  of  a  system  Data 
Entity  that  is  used  recursively,  which  decomposes  the  equipment  into 
only  those  components  that  are  being  maintained  or  operated. 

Each  component  of  this  hierarchy  has  associated  with  it  at  least  the 
following  five  categories  of  information  (composite  elements): 
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( 1 )  Descriptive  Information 

(2)  Procedural  Information 

(3)  Operational  Information 

(4)  Troubleshooting  Information 

(5)  Parts  Information. 


3.2.2  Descriptive  Information 

Descriptive  Information  provides  information  on  system  (subsystem, 
component,  part)  physical  arrangement,  functional  behavior,  theory  of 
operation,  and  other  aspects.  Descriptive  Information  contains  a 
hierarchy  of  narrative  paragraphs.  Paragraphs,  in  turn,  may  refer  to 
primitive  Data  Entities.  (See  Section  3.2.7.) 


3.2.3  Procedural  Information 


Procedural  Information  is  directive,  and  is  composed  primarily  of  task 
statements.  Each  task  Data  Entity  must  be  associated  with  Attributes 
which  provide  such  related  information  as:  estimated  completion  time; 
maintenance  level (s)  where  the  task  is  to  be  performed;  required 
conditions  which  must  be  met  before  performing  the  task;  and  the  number 
of  people  required  to  perform  the  task.  A  Procedural  Data  Element  may 
be  linked  to  other  Data  Entities  which  define  the  support  equipment  and 
consumables  that  task  requires,  through  the  establishment  of  appropriate 
Relationships . 


3.2.4  Operational  Information 

Operational  information  contains  a  combination  of  Descriptive 
Information  and  Procedural  Information,  such  as  checklists,  which  is 
required  for  operating  the  system  as  a  whole. 


3.2.5  Troubleshooting  Information 

Data  Entities  consisting  of  troubleshooting  information  contain  data 
necessary  to  isolate  faults  found  in  a  system.  Fault  isolation  is 
defined  as  identification  of  all  defective  components  or  parts 
responsible  for  the  fault.  Such  data  may  consist  of  traditional  fault¬ 
reporting  and  fault-isolation  logic  trees,  or  may  provide  highly 
interactive  dynamic  fault-isolation  procedures.  Troubleshooting 
information  contains  Fault  Entities,  Fault  State  Entities,  Test 
Entities,  Outcome  Entities,  and  Rectification  Entities. 
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3. 2 .5.1  Fault  Entities 


A  Fault  Entity  may  contain  a  variety  of  information  providing  support 
to  the  end  user  in  performing  a  fault-isolation  action.  For  example,  it 
may: 

a.  Describe  the  proper  performance  of  a  component  or  part  as 
contrasted  with  observed  faulty  performances; 

b.  Cite  a  part  within  a  system  which  has  been  observed  to  contain  a 
fault; 

c.  Cite  an  MTBF  value  expected  for  a  system  when  a  given  part  is  at 
fault . 


3. 2. 5. 2  Fault  State  Entities 

A  Fault  State  Data  Entity  presents  a  fault  or  list  of  faults  suspected 
or  implicated  as  the  result  of  a  test  that  has  been  performed.  Each 
suspected  fault  in  the  list  may  be  weighted,  based  on  the  probability 
that  it  shall  be  the  cause  of  the  observed  malfunction.  The  Fault  State 
Data  Entity  may  also  present  a  list  of  possible  faults  that  have  been 
eliminated  from  consideration  as  the  result  of  tests  performed.  Fault 
states  may  also  present  the  next  best  test,  based  on  original 
engineering  predictions. 


3. 2. 5. 3  Test  Entities 


Test  Entities  contain  list  the  procedural  instructions  a  technician 
must  follow  to  carry  out  a  required  task  at  a  particular  juncture  in  the 
troubleshooting  procedure.  Test  Entities  also  provide  all  possible  test 
outcomes . 


3. 2. 5. 4  Outcome  Entities 


Outcome  Entities  contain  definitions  of  new  fault  states  associated 
with  the  results  of  a  particular  test.  Outcome  Entities  also  contain  a 
description  of  the  state  of  the  item  being  maintained.  An  outcome  is 
based  one  or  more  preconditions,  system  states  which  must  be  established 
for  the  specific  outcome  to  apply.  The  final  Outcome  Entity  of  a  fault- 
isolation  procedure  shall  have  a  Relationship  which  associates  it  with 
the  initial  Data  Entity  of  the  appropriate  corrective-maintenance 
procedure  involved  in  correcting  the  identified  fault  (e.g.,  a  remove- 
and-replace  procedure). 


3. 2. 5. 5  Rectification  Entities. 
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Rectification  entities  contain  references  to  procedural  rectification 
tasks,  checkout  tests  used  to  report  the  success  of  completed 
rectification  tasks,  and  a  list  of  all  faults  that  the  rectification 
shall  repair. 


3.2.6  Parts  Information 


The  two  types  of  parts  information  include:  (1)  maintenance/operation 
information  and  (2)  supply  information.  Data  Entities  containing  either 
type  shall  refer  explicitly  to  corresponding  Entities  of  the  other  type. 


3.2.6. 1  Parts  Information  for  the  Maintainer  or  Operator 

Parts  information  provided  for  a  system  maintainer  and/or  operator 
shall  include  such  items  as  units  per  assembly,  usable-on  code,  MTBF, 
and  reference  designators. 


3. 2. 6. 2  Parts  Information  Provided  for  Parts  Supply 

Parts  information  provided  for  the  parts-supply  process  must 
constitute  unambiguous  identification  of  a  part  so  that  it  can  be 
reordered,  and  must  consist  of  such  items  as:  the  part  number; 

Commercial  And  Government  Entity  number  (CAGE);  Source,  Maintainability, 
and  Reliability  ( SMR)  code;  Hardness  Critical  Item  (HCI)  code;  and 
National  Stock  Number  (NSN ) . 


3.2.7  Primitive  Entities 


Each  Data  Entity  containing  a  composite  of  Technical  Information  of 
the  types  described  in  Sections  3.2.1  through  3.2.6  shall  cite  one  or 
more  primitive  Entities.  Primitive  Entities  can  be  shared  by  (related 
to)  more  than  one  composite  Entity.  This  data-base  structure  reduces 
the  redundancy  and  volume  of  information  which  must  be  stored.  It  also 
improves  configuration  management  of  the  data  by  minimizing  the  number 
of  Data  Entities  in  which  changes  need  to  be  made.  Eight  basic  types  of 
primitive  Technical  Information  Data  Entities  are  described  in  the 
subsequent  paragraphs . 


3.2.7. 1  Textual  Information 


Textual  Information  consists  of  alphanumeric  (character)  data 
consisting  of  letters,  words,  sentences,  paragraphs,  numbers,  etc. 
Textual  Information  may  also  contain  embedded  references  to  some  higher- 
level  Data  Entities  such  as  those  describing  parts  or  consumables. 
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3.2. 7.2  Graphics 

Graphics  (drawings,  illustrations)  information  is  hierarchical  and 
object-oriented.  Graphic  primitives  can  be  combined  to  produce 
composite  information  which  can  be  referenced  and  selected.  Parts 
information  may  consist  of  graphics.  Graphics  can  be  composed  of 
primitive  information  represented  in  accordance  with  a  variety  of 
graphic  standards,  which  must  be  identified  (see,  for  example, 
M1L-D-28003)  . 


3 . 2 . 7 . 3  Tables 


Tables  are  represented  as  a  series  of  separate  entries,  each  entry 
being  associated  with  a  specific  row-and-column  intersection  (cell)  of  a 
table.  Each  row  and  column  of  the  table  may  be  associated  with  types  of 
information  presentation  and  Attributes.  Each  entry  (cell)  may  refer 
(through  a  Relationship)  any  other  composite  or  primitive  Entity  in  the 
Technical  Information  Data  Base. 


3. 2. 7. 4  References 


Cross-reference  information  is  represented  as  a  Data  Entity  which  can 
be  referenced  by  (related  to)  other  composite  Entities,  and  which  itself 
refers  to  other  composite  or  primitive  Entities.  A  Cross-reference 
Entity  can  also  refer  to  processes  or  information  outside  the  IETMDB, 
such  as  an  external  diagnostic  procedure  or  some  standard  reference 
material.  A  Cross-reference  Entity  can  be  associated  with  a  type  of 
information  presentation,  such  as  schematic  reference  or  theory-of- 
operation  reference. 


3. 2. 7. 5  Messages  (Warnings,  Cautions,  Notes) 

Procedural  Information  instructs  a  user  to  perform  tasks  and  steps. 
Warnings,  Cautions,  and  Notes  which  help  the  user  perform  the  required 
task  or  step  more  effectively  or  more  safely  can  be  referenced.  These 
Entities  may,  in  turn,  reference  more  primitive  Entities,  such  as  text. 


3. 2. 7. 6  Prompts.  Assertions.  Properties 

Prompt  Entities  are  required  when  the  Author  determines  that  specific 
information  should  be  presented  to  the  user  based  on  some  property  that 
the  user  has  observed.  Prompt  Entities  contain  prompting  questions  and 
associated  properties  which  depend  on  the  user's  response.  For  example: 
”  'is  there  oil  on  the  ground?'  If  so,  then  perform  Task  A;  otherwise, 
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perform  Task  B."  These  properties  are  represented  so  that  a  human- 
readable  version  of  the  property  can  be  created,  even  though  a  machine 
can  perform  Boolean  logic  on  the  property. 

Some  Data  Entities  may  have  assertions  which  are  property-value  pairs 
to  be  asserted  by  the  Display  System  software  whenever  the  paragraph  or 
step  is  executed  by  the  user.  Once  these  property  values  are  asserted, 
they  shall  be  accessible  to  the  presentation  software  for  later  testing 
and  processing  to  determine  the  user's  context.  For  example,  after 
completing  a  procedure  to  open  access  panel  No.  Ill,  the  assertion 
"access  panel  No.  Ill  =  open"  might  be  stated  by  the  system.  This 
statement  could  later  be  used  by  a  checkout  procedure  which  requires 
that  the  access  panel  be  open  as  a  precondition  for  performing  a  test. 

In  Electronic  Display  Systems,  properties  can  sometimes  be  asserted 
without  prompting.  For  example,  if  Task  A  instructs  the  user  to  close  a 
panel,  the  system  can  assert  that  the  panel  has  been  closed  when  the 
user  completes  Task  A. 


3. 2. 7. 7  Precondition  Entities 


The  Precondition  Entity  is  similar  to  the  Assertion  Entity.  An 
Assertion  Entity  tells  the  Display  System  to  assert  that  a  property  is 
true  or  false;  the  Precondition  Entity  tells  the  Display  software  to 
test  whether  a  property  is  true  or  false.  Precondition  Entities  can  be 
referenced  by  composite  Entities.  This  process  shall  imply  that  the 
composite  Entity's  information  is  relevant  only  if  a  property  is  true  or 
false.  For  example,  a  precondition  that,  in  effect,  says,  "Show  these 
steps  only  if  the  voltage  on  pin  5  is  greater  than  6  volts"  may  be 
attached  to  a  Data  Entity  containing  specific  task  statements. 


3 . 2 . 7 . 8  Context 


Context  attributes  work  in  a  manner  similar  to  precondition  entities 
(see  paragraph  3. 2. 7. 7.).  If  an  entity  has  one  or  more  context 
attributes,  the  information  associated  with  the  entity  is  only 
appropriate  if  the  context  of  the  user's  situation  matches  the  set  of 
context  attributes.  Two  versions  of  the  same  task  may  exist,  each  with 
different  context  attributes.  Depending  on  the  context  of  the  user's 
situation,  the  appropriate  task  shall  be  displayed.  Examples  of  context 
attributes  include:  system  configuration,  security  of  the  information, 
version  of  the  information,  and  user-defined  precondition  entities. 


3 . 2 . 7 . 9  Other  Primitives 


Other  primitive  Entities  may  be  involved  in  the  IETMDB.  For  example, 
Descriptive-Information  and  Procedural  Data  Entities  shall  have  the 
capability  to  reference  video  processes  and  programmed  processes  as 
needed.  A  task  or  step  Data  Entity  shall  reference  the  number  and  type 
of  personnel  required,  a  list  of  support  equipment,  and  a  list  of 
consumables  required  to  complete  the  task  or  step. 
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3.3  Creation  of  the  IETMDB 


The  IETMDB  is  constructed  to  support  the  generation  of  Interactive 
Electronic  Technical  Manuals  (IETMs)  through  the  use  and  creation  of 
View  Packages ,  and  to  enable  the  Government  and  its  Contractors  to 
derive  a  variety  of  technical  reports  for  system  operation  and  logistics 
support.  Requirements  for  features  (options)  of  the  IETMDB  required  for 
these  purposes  shall  be  contained  in  the  Contract  or  order,  either  as 
part  of  the  associated  IETM  and  View  Package  Specifications,  or  as 
explicit  statements  in  the  Contract  Schedule. 

In  general,  it  is  the  acquiring  activity's  responsibility  to  develop 
guidelines  that  govern  the  creation  of  the  revisable,  integrated 
technical  information  database.  Issues  that  the  acquiring  activity 
shall  address  to  ensure  the  technical  information  and/or  database  it 
receives  meets  its  requirements  are  defined  in  the  following  paragraphs. 


3.3.1  Level  of  Detail.  Multiple  Tracks 

The  IETMDB  can  present  task  statements  at  both  the  "expert"  and  the 
"novice"  levels  (tracks).  (See  Section  3. 1.2. 2. 4.)  Which  option  is 
required  (or  whether  both  are)  is  a  necessary  input  for  IETMDB  design. 
The  default  condition  shall  be  presentation  at  the  "novice"  level  only. 


3.3.2  Data  Content  and  Information-Presentation  Type  Conventions 

Composite  Data  Entities  of  the  IETMDB  can  reference  (be  related  to) 
almost  any  other  primitive  or  composite  Entity,  including  Entities  which 
identify  the  type  of  information  presentation  employed  by  the  Entity.  A 
design  input  for  the  IETMDB  is  the  designation  by  the  Acquiring  Agency 
of  the  spectrum  of  information-presentation  types  to  be  required  (in  the 
IETMs,  View  Packages,  or  other  reports).  See,  for  example,  MIL-M-GCSFUI 
and  MIL-HDBK-IETMVP . 


3.3.3  Numbering  and  Naming  Conventions 

Entities  in  the  IETMDB  containing  information  on  individual  components 
of  the  weapon-system  hierarchy  require  numbers  and  names.  The  acquiring 
Activity  shall  provide  suitable  and  consistent  numbering  and  naming 
conventions  for  weapon  systems  (or  other  equipment). 
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3.3.4  Allowable  Context  Attributes 


Certain  Context  Attributes  may  not  be  applicable  to  the  IETMDB 
information  associated  with  a  particular  system.  The  Acquiring  Activity 
shall  delineate,  when  the  LSAR  does  not  provide  complete  guidance,  which 
Context  Attributes  apply  and  what  values  are  allowable  for  each  Context 
Attribute.  The  Acquiring  Activity  may  also  choose  to  limit  the  types  of 
user-defined  precondition  Attributes. 


3.3.5  Required  References 

The  Acquiring  Activity  may  request  specific  cross  references  to  Data 
Entities  within  the  IETMDB  and  to  information  sources  outside  the 
IETMDB . 


3.3.6  Logistics-Support  and  Task-Analysis  Link 

The  Acquiring  Activity  may  specify  the  establishment  of  linkages 
(information-access  capabilities)  between  the  IETMDB  and  external 
logistics-support  and  task-analysis  systems. 


3.3.7  Text  and  Graphics  Conventions 


Data  Entities  in  the  IETMDB  shall  be  free  of  Format  and  Style 
requirements.  Graphics  shall  conform  to  the  requirements  MIL-STD-1840A. 


3.4  Data  Base  and  Data  Maintenance  Requirements 


3.4.1  Data  Base  Management  Summary 

The  Contractor  shall  submit  to  the  Government  a  report  accompanying 
the  IETMDB  which  shall  completely  describe  the  processes  of  Data  Base 
management  and  Data  Base  maintenance  implicit  in  the  design  of  the 
IETMDB. 


3.4.2  Use  of  the  IETMDB 

The  IETMDB  shall  serve  as  the  single  basis  for  the  generation  of 
system- relevant  Interactive  Electronic  Technical  Manuals  and  (through 
the  use  of  automated  processes)  of  View  Packages.  Other  uses  involving 
access  by  Government  Activities  or  Government  Contractors,  or  by 
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automated  information  systems,  shall  be  as  specified  by  the  Acquiring 
Activity. 


3.4.3  Data  Revisabilitv 

The  IETMDB  shall  be  designed  to  permit  simple  straightforward 
techniques  of  Data  Entity  revision  by  both  the  Contractor  and  the 
Government.  Specifically: 


a.  Changed  Data  Entities  shall  be  revalidated  as  required  by 
MIL-M- IETMQA. 

b.  Incorporation  of  any  change  (update)  must  automatically  update 
all  aspects  of  the  Data  Base  affected  by  that  change.  (See 
Section  1.2.2.) 

c.  An  audit  trail  of  all  changes  made  to  any  item  of  accessed 
information  must  be  available  to  a  user  of  the  IETMDB. 


3.4.4  File  Access  Requirements 

Multipath  on-line  access  shall  be  provided  to  relevant  Data  Entities. 
Such  access  shall  at  least  include  access  paths  based  on  any  task 
identified  in  the  LSAR,  nomenclature  of  any  identified  item  in  the 
weapon-system  or  equipment  hierarchy,  and  keyword  search.  Establishment 
of  other  specific  access  paths  may  be  requested  by  the  Government. 


3.4.5  Configuration  Management 

Contextual  Attributes  attached  to  each  Data  Entity  must  make 
completely  clear  the  version  (model)  of  the  weapon  system  or  equipment 
to  which  the  Data  Entity  applies. 


A  record  of  all  IETMDB  modifications  made  must  be  available  to  an  end 
user  as  a  special  report  observable  by  means  of  an  EDS.  A  summary  of 
all  versions  of  the  system  supported  (e.g.,  by  individual  aircraft  tail 
numbers)  must  be  obtainable  by  an  end  user. 


Where  more  than  one  alternate  edition  of  a  Technical  Information 
increment  is  supported  by  the  IETMDB  (e.g.,  maintenance  processes  for  a 
series  of  aircraft  systems,  some  of  which  have  been  modified),  the 
different  versions  shall  be  kept  completely  separate.  (See  Section 
3. 2. 7. 6.) 
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3.4.6  Capability  for  Growth 

The  database  shall  be  designed  and  implemented  by  the  Contractor 
utilizing  modular  construction  to  allow  for  growth,  technical  advances, 
and  extensibility.  Modular  design  methods  shall  be  utilized  to  minimize 
the  time  and  effort  required  for  adding  system  enhancements,  interfaces, 
and  processes. 

The  IETMDB  must  be  designed  so  that  additional  Data  Entities,  with 
Associated  Attributes  and  Relationships,  can  be  easily  incorporated  into 
the  overall  data  base  design,  and  sufficient  data-storage  capacity  and 
processing  capability  must  be  available  to  handle  the  data  volume  and 
growth  requirements  that  are  specified  in  the  contract. 


3.5  Preparation  for  Delivery  to  the  Government 
[Text  for  this  section  to  be  supplied  later.] 


4.  QUALITY  ASSURANCE  PROVISIONS 

Quality  Assurance  for  the  IETMDB  preparation  shall  be  in  accordance 
with  the  requirements  of  MIL-M- IETMQA. 


5 .  PACKAGING 

Delivery  (or  other  interchange)  of  the  digital  data  stream 
constituting  the  IETMDB  shall  require  that  the  IETMDB  be  put  into  the 
form  specified  by  MIL-STD-1840A.  Alternatively,  the  Acquiring  Activity 
may  invoke  in  the  Contract  a  specification  subsidiary  to  MIL-STD-I840A, 
which  relates  MIL-STD-1840A  requirements  more  particularly  to  a  Data 
Base  of  the  IETMDB  type  as  compared  to  product-data  interchange. 


6.  DATA  ELEMENT  DICTIONARY  AND  DATA  BASE  STRUCTURE 


Appendix  A  provides  a  Data  Element  Dictionary  which  lists,  describes, 
and  names  the  minimum  set  of  Data  Entities,  with  their  Attributes  and 
Relationships,  required  for  the  IETMDB.  Inclusion  of  other  Data 
Entities  may  be  required  by  the  Contract. 


Although  this  Specification  requires  no  specific  language  or  data-base 
structure,  Appendixes  B  through  E  are  included  as  examples  of 
satisfactory  approaches  to  IETMDB  structure  based  on  IDEF1X  (Appendix 
B),  on  EXPRESS  (Appendix  C),  on  the  Nijssen  Information  Analysis 
Methodology  [NIAM]  (Appendix  D),  and  on  an  SGML-tagged  object-oriented 
design  (Appendix  E). 


19 


1  Jun  90 


APPENDIXES 


MIL-M-IETMDB 
1  June  1990 


APPENDIX  A 
APPENDIX  B 
APPENDIX  C 

APPENDIX  D 

APPENDIX  E 


:  DRAFT  DATA-ELEMENT  DICTIONARY  OF  REVISABLE  IETM  DATABASE 

:  IDEF1X  REPRESENTATION  OF  REVISABLE  IETM  DATABASE 

:  EXPRESS  REPRESENTATION  OF  REVISABLE  IETM  DATABASE  (to  be 
provided  by  AFHRL) 

:  NIAM  REPRESENTATION  OF  REVISABLE  IETM  DATABASE  (to  be 
provided  by  AFHRL) 

:  SGML  REPRESENTATION  OF  REVISABLE  IETM  DATABASE 
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APPENDIX  A 

DATA  ELEMENT  DICTIONARY  OF  REVISABLE  IETM  DATABASE 


1.0  INTRODUCTION. 

The  Interactive  Electronic  Technical  Manual  (IETM)  data  element  dictionary 
(DED)  identifies  and  defines  all  required  technical  information  entities 
and  attributes.  The  DED  also  defines  relationships  between  the  entities. 
This  appendix  consists  of  two  sections.  Section  One  contains  definitions 
of  entities  and  lists  the  relationships  of  each  entity  to  other  database 
entities.  Section  Two  defines  all  identified  attributes  for  IETM  entities. 

2.0  SECTION  ONE:  ENTITY  DEFINITIONS  AND  RELATIONSHIPS. 

Section  One  contains  definitions  of  the  entities  which  exist  in  Interactive 
Electronic  Technical  Manuals  ( IETMs ) .  An  entity  is  an  object  about  which 
we  keep  information  or  facts.  An  entity  may  be  a  real,  physical  object, 
such  as  an  employee  or  a  machine;  or  it  may  be  an  abstract  object,  such  as 
a  schedule  or  event. 

2 . 1  CONTENT . 

This  section  contains  some  or  all  of  the  following  entries: 

a.  Entity  Name 

b.  Entity  Short  Descriptive  Name 

c.  Entity  Definition 

d.  Entity  Relationships. 

2 . 2  FORMAT . 

The  general  format  of  Section  One  of  the  Data  Element  Dictionary  is  as 
follows : 

NAME  SHORT  DESCRIPTION 

DEFINITION 

ENTITY  RELATIONSHIPS 
Here  is  an  example  of  an  entity  entry: 

EQUIP  Maintenance  Equipment 

Identifies  the  equipment  needed  to  perform  a  particular  task  or  step. 
Usually  refers  to  a  piece  of  test  equipment,  tool,  or  support  equipment. 

Entity  Relationships: 

An  EQUIP  is  required  by  zero,  one,  or  more  TASKS. 

An  EQUIP  is  required  by  zero,  one,  or  more  STEPS. 

An  EQUIP  refers  to  zero,  one,  or  more  ALTEQUIDs. 

An  EQUIP  contains  one  CONTEXT. 


A-l 


1  Jun  90 


i 


MIL-M- IETMDB 
1  June  1990 


2.3  DEFINITION  OF  TERMS. 

2.3.1  Entity  Name. 

The  entity  name  is  a  short  name  used  to  uniquely  identify  the  data  entity. 

2.3.2  Entity  Short  Description. 

The  short  description  ia  a  short  noun  phrase  used  to  more  clearly  identify 
and  describe  the  data  entity. 

2.3.3  Entity  Definition. 

The  entity  definition  contains  a  narrative  definition  of  the  data  element. 

2.3.4  Entity  Relationships. 

A  relationship  establishes  the  fact  that  an  entity  is  paired  with  another 
entity  in  some  manner.  These  relationships  are  identified  in  this  portion 
of  the  DED.  All  entity  names  are  shown  in  capital  letters. 


3.0  SECTION  TWO:  ATTRIBUTE  DEFINITIONS. 

Section  two  contains  definitions  of  all  identified  attributes  of  the  IETM 
entities.  An  attribute  of  an  entity  is  data  which  represents  a  property, 
or  characteristic,  of  the  entity.  To  be  an  attribute  of  an  entity,  the 
attribute  must  occur  only  once  for  an  instance  of  the  entity. 


3.1  CONTENT. 

This  section  contains  some  or  all  of  the  following  entries: 

a)  Attribute  Name 

b)  Attribute  Descriptive  Name 

c )  Data  Format 

d)  Description 

e)  LSAR  Reference 

f)  Attribute  of:  listing. 

3 . 2  FORMAT . 

The  general  format  of  Section  Two  of  the  Data  Element  Dictionary  is  as 
follows : 

Attribute  Name  Attribute  Descriptive  Name 

Data  Format: 

Description 
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LSAR  Reference 
Attribute  of:  Listing 


Here  is  an  example  of  an  attribute  entry: 

MTBF  Mean  Time  Between  Failures 

Data  Format:  9(10)  Right 

For  a  particular  interval,  the  total  functional  life  of  a  population  of  an 
item  divided  by  the  total  number  of  failures  within  the  population  during 
the  measurement  interval.  The  definition  holds  for  time,  rounds,  miles, 
events,  or  other  measure  of  life  units. 

LSAR:  204  -  Mean  Time  Between  Failures  (MTBF) 

Attribute  of:  FAULT,  PARTINFO 


3.3  DEFINITION  OF  TERMS. 


3.3.1  Attribute  Name. 

The  attribute  name  is  a  short  name  used  to  identify  an  attribute  of  an 
entity. 

3.3.2  Attribute  Descriptive  Name. 

The  attribute  descriptive  name  is  a  short  noun  phrase  used  to  more  clearly 
identify  and  describe  the  attribute. 

3.3.3  Data  Format. 


The  data  format  contains  the  format  for  the  attribute.  Most  data  formats 
consist  of  three  fields: 


1 )  Type 

2 )  Length 

3)  Justification. 


3 . 3 . 3 . 1  Type . 


A  -  All  characters  are  alphabetic. 

9  -  All  characters  are  numeric. 

X  -  Characters  are  any  combination  of  alphabetic,  numeric,  or 
special  characters . 
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3. 3. 3. 2  Length. 

The  data  length  specifies  the  maximum  number  of  characters  contained  in  the 
attribute.  The  length,  in  parentheses,  follows  the  type  indicator  in  the 
data  format. 

3. 3. 3. 3  Justification. 

Left  -  Left- justified. 

Right  -  Right- justified. 

Fixed  -  Fixed:  occupies  the  entire  field. 

3. 3. 3. 4  Narrative. 

Some  attributes  will  indicate  a  data  format  of  Narrative.  Narrative 
indicates  extended  narrative  data  fields,  capable  of  accepting  a  maximum 
of  65,536  characters  of  information. 

3.3.4  Description. 

A  narrative  definition  of  the  attribute. 


3.3.5  LSAR  Reference. 

Indicates  an  associated  data  item  within  the  Logistics  Support  Analysis 
Record  (LSAR).  These  items  are  found  in  MIL-STD-1388-2B,  Appendix  E. 


3.3.6  Attribute  of:  Listing. 


Identifies  which  entities  within  the  revisable  data  base  contain  the 
current  attribute. 
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SECTION  ONE 

DATA  ELEMENT  DICTIONARY 
ENTITY  DEFINITIONS 


ALTEQUID  Alternate  Equipment 

The  ALTEQUID  identifies  alternate  pieces  of  equipment,  by  either  Alternate 
Name/Alternate  Equipment  ID  (AN/AE1D),  or  commercial  or  manufacturer 
designation,  which  may  be  used  in  substitution  of  a  specific  piece  of 
equipment . 

Entity  Relationships: 

An  ALTEQUID  refers  to  one  EQUIP. 

An  ALTEQUID  contains  one  CONTEXT. 


ANNOT  User  Annotation 

This  entity  references  a  comment  from  the  technician.  Annotations  can  be 
made  for  descriptive  information  or  for  a  specific  step  within  a  procedural 
task. 


Entity  Relationships: 

An  ANNOT  is  referenced  by  zero,  one,  or  more  DESCINFOs. 
An  ANNOT  is  referenced  by  zero,  one,  or  more  STEPS. 

An  ANNOT  refers  to  zero,  one,  or  more  XREFs . 

An  ANNuT  displays  one  TEXT. 

An  ANNOT  contains  one  CONTEXT. 


ASSERTION  Assertion 


An  ASSERTION  is  a  fact,  defined  in  terms  of  a  PROPERTY /VALUE  pair,  which 
expresses  an  author-defined  property  to  be  affirmed  as  the  system  processes 
the  STEP  or  DESCINFO  in  question. 


Entity  Relationships: 

An  ASSERTION  is  asserted  by  zero,  one,  or  more  DESCINFOs. 
An  ASSERTION  is  asserted  by  zero,  one,  or  more  STEPS. 

An  ASSERTION  asserts  zero,  one,  or  more  PROPERTY /VALUES . 
An  ASSERTION  contains  one  CONTEXT. 
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AUDIO  Audio  Data 

This  entity  references  an  external  audio  sequence  which  may  be  represented 
as  a  file  or  some  other  external  reference. 

Entity  Relationships: 

An  AUDIO  process  is  invoked  by  zero,  one,  or  more  DESCINFOs. 

An  AUDIO  process  is  invoked  by  zero,  one,  or  more  STEPS. 

An  AUDIO  process  refers  to  zero,  one,  or  more  XREFs . 

An  AUDIO  contains  one  CONTEXT. 


CAUTION  Caution 

A  CAUTION  is  used  in  technical  information  to  emphasize  a  procedure  that, 
if  not  strictly  followed,  or  a  condition  that,  if  not  strictly  maintained, 
may  result  in  damage  to  the  equipment. 

Entity  Relationships: 

A  CAUTION  is  presented  by  zero,  one,  or  more  TASKS. 

A  CAUTION  is  presented  by  zero,  one,  or  more  STEPS. 

A  CAUTION  displays  one  TEXT. 

A  CAUTION  refers  to  zero,  one,  or  more  XREFs. 

A  CAUTION  contains  one  CONTEXT. 


CHOICE  Choice  of  a  Menu 

This  entity  references  one  item  in  the  list  of  possible  selections  within 
a  menu. 

Entity  Relationships: 

A  CHOICE  has  zero,  one,  or  more  VALUES. 

A  CHOICE  is  contained  in  one  MENU. 

A  CHOICE  displays  one  TEXT. 

A  CHOICE  contains  one  CONTEXT. 


CODEWORD  Codeword  Designation 

A  CODEWORD  is  used  when  access  to  a  specific  entity  is  limited  to  a  select 
group  of  people.  The  context  of  that  entity  will  have  a  codeword  (i.e. 
password)  associated  with  it. 

Entity  Relationships: 

A  CODEWORD  is  contained  in  one  CONTEXT. 
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COLHDDEF  Column  Heading  Definition 

This  entity  identifies  the  column  heading  definitions  portion  of  tabular 
information . 

Entity  Relationships: 

A  COLHDDEF  is  contained  in  one  TABLE. 


CONFIG  Configuration 

This  entity  represents  the  conf iguration  of  the  current  system  being 
maintained.  This  allows  the  system  to  automatically  choose  the  correct 
path  according  to  the  configuration  that  has  been  entered  into  the  system. 
The  CONFIG  is  based  on  effectivity  codes  in  current  technical  orders. 

Entity  Relationships: 

A  CONFIG  is  contained  in  one  CONTEXT. 


CONSUM  Consumable  Supply 

This  entity  identifies  information  about  a  consumable  item  that  is  required 
fcr  procedural  tasks  or  steps. 

Entity  Relationships: 

A  CONSUM  is  required  by  zero,  one,  or  more  TASKS. 

A  CONSUM  is  required  by  zero,  one,  or  more  STEPS. 

A  CONSUM  refers  to  zero,  one,  or  more  XREFs . 

A  CONSUM  contains  one  CONTEXT. 


CONTEXT  Effectivity  Analysis 

CONTEXT  references  a  set  of  frequently-used  effectivity  attributes  and  a 
list  of  user-defined  preconditions  to  ensure  proper  traversal  of  database 
information  to  provide  the  correct  information  to  the  technician  for  the 
current  system  being  maintained/repaired. 

Entity  Relationships: 


A 

CONTEXT 

is  contained  in  ALL 

ENTITIES. 

A 

CONTEXT 

contains 

zero, 

one , 

or 

more 

VERSIONS. 

A 

CONTEXT 

contains 

zero , 

one. 

or 

more 

TRACKS. 

A 

CONTEXT 

contains 

zero, 

one, 

or 

more 

CONFIGs. 

A 

CONTEXT 

contains 

zero. 

one , 

or 

more 

SECURITYs . 

A 

CONTEXT 

contains 

zero, 

one. 

or 

more 

RESTRICTS . 

A 

CONTEXT 

contains 

zero, 

one. 

or 

more 

RELEASES . 

A 

CONTEXT 

contains 

zero, 

one , 

or 

more 

CODEWORDS . 

A 

CONTEXT 

contains 

zero. 

one. 

or 

more 

SCILEVELS . 

A 

CONTEXT 

contains 

zero, 

one , 

or 

more 

DIGLYFHs. 

A 

CONTEXT 

tests  zero,  one,  or 

more  PRECONDs . 

A 

CONTEXT 

contains 

zero, 

one. 

or 

more 

MAINTLVLs . 

A 

CONTEXT 

contains 

zero, 

one, 

or 

more 

VERSTATs . 

A-  7 


1  Jun  90 


MIL-M-IETMDB 
1  June  1990 


DESCINFO  Descriptive  Information 

Descriptive  information  is  used  to  define  general-purpose,  non-procedural, 
narrative  information  such  as  theory  of  operation,  schematics,  or  wiring 
diagrams.  DESCINFO  is  a  flexible,  general-purpose  information  entity.  A 
descriptive  information  entity  could  be  thought  of  as  a  piece  of  a  textual 
document.  These  pieces  could  consist  of  a  group  of  chapters,  sections, 
paragraphs  or  individual  paragraphs,  sentences,  etc.  Each  descriptive 
information  entity  points  to  the  next  descriptive  information  entity  to  be 
presented. 

Entity  Relationships: 

A  DESCINFO  is  referenced  by  zero,  one,  or  more  SYSTEMS. 

A  DESCINFO  is  referenced  by  zero,  one,  or  more  OPERINFOs. 

A  DESCINFO  refers  to  zero,  one,  or  more  SUBDESCINFOs . 

A  DESCINFO  asserts  zero,  one,  or  more  ASSERTIONS. 

A  DESCINFO  presents  zero,  one,  or  more  TABLES. 

A  DESCINFO  displays  zero,  one,  or  more  GRAPHICS. 

A  DESCINFO  invokes  zero,  one,  or  more  AUDIO  processes. 

A  DESCINFO  invokes  zero,  one,  or  more  VIDEO  processes. 

A  DESCINFO  refers  to  zero,  one,  or  more  XREFs . 

A  DESCINFO  invokes  zero,  one,  or  more  PROCESSes. 

A  DESCINFO  displays  zero  or  one  TEXT. 

A  DESCINFO  presents  zero,  one,  or  more  PROMPTS. 

A  DESCINFO  refers  to  zero,  one,  or  more  ANNOTs. 

A  DESCINFO  contains  one  CONTEXT. 


DIGLYPH  Security  Classification  Code 

This  entity  represents  a  two-character  code  which  relates  to  security 
classifications . 

Entity  Relationships: 

A  DIGLYPH  is  contained  in  one  CONTEXT. 


ELMNTREF  Element  Reference 

The  ELMNTREF  references  any  entity  within  the  IETM  database  by  the  entity's 
reference  identifier  (refid) . 

Entity  Relationships: 

An  ELMNTREF  is  referenced  by  zero,  one,  or  more  ENTRYs. 

An  ELMNTREF  is  contained  in  zero,  one,  or  more  XREFs. 

An  ELMNTREF  refers  to  one  OF  ANY  ENTITY  IN  THE  DATABASE. 

An  ELMNTREF  is  referenced  by  zero,  one,  or  more  PROPERTYs. 
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ENTRY  Table  Entry 

An  ENTRY  references  a  "cell"  (a  specific  row  and  column)  of  a  table,  which 
may  take  the  form  of  text  or  any  other  internal  entity. 

Entity  Relationships: 

An  ENTRY  is  contained  in  one  TABLE. 

An  ENTRY  refers  to  zero  or  one  ELMNTREFs . 

An  ENTRY  refers  to  zero  or  one  TEXT. 


EQUIP  Maintenance  Equipment 

This  entity  identifies  the  equipment  needed  to  perform  a  particular  task 
or  step.  EQUIP  usually  refers  to  a  piece  of  test  equipment,  support 
equipment,  or  tool. 

Entity  Relationships: 

An  EQUIP  is  required  by  zero,  one,  or  more  TASKS. 

An  EQUIP  is  required  by  zero,  one,  or  more  STEPS. 

An  EQUIP  refers  to  zero,  one,  or  more  ALTEQUIDs. 

An  EQUIP  contains  one  CONTEXT. 


EXPFAULT  Exculpated  (Excluded)  Fault 

This  entity  references  a  list  of  faults  that  are  known  to  be  good,  or 
"exculpated"  from  blame  in  a  particular  fault  state. 

Entity  Relationships: 

An  EXPFAULT  is  identified  by  one  FLTSTATEs . 

An  EXPFAULT  identifies  one  FAULT. 


FAULT  Fault  Code 

This  entity  identifies  a  potential  failure  that  may  occur  within  a  system. 
Entity  Relationships: 

A  FAULT  is  identified  by  zero,  one,  or  more  FAULTINFs. 

A  FAULT  identifies  one  or  more  RECTs . 

A  FAULT  points  to  zero,  one,  or  more  PARTINFOs. 

A  FAULT  displays  zero  or  one  TEXT. 

A  FAULT  refers  to  zero,  one,  or  more  XREFs . 

A  FAULT  identifies  zero,  one,  or  more  FLTSTATEs. 

A  FAULT  is  identified  by  zero,  one,  or  more  EXP FAULTS . 

A  FAULT  is  identified  by  zero,  one,  or  more  IMPFAULTs. 

A  FAULT  contains  one  CONTEXT. 
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FAULT INF  Fault  Information  Data 

This  entity  references  a  collection  of  troubleshooting  information  that 
pertains  to  a  given  system. 

Entity  Relationships: 

A  FAULTINF  is  referenced  by  zero,  one,  or  more  SYSTEMS. 

A  FAULTINF  identifies  one,  or  more  FAULTS. 

A  FAULTINF  refers  to  zero,  one,  or  more  XREFs . 

A  FAULTINF  identifies  one,  or  more  TESTS. 

A  FAULTINF  contains  one  CONTEXT. 


FILLIN  Fill-In-The-Blank 

FILLIN  references  a  f ill-in-the-blank  form  that  will  be  displayed  to  the 
technician.  This  entity  is  a  type  of  system  prompt;  it  can  have  a  default 
text  string  for  its  initial  entry  in  the  f ill-in-the-blank  form. 

Entity  Relationships: 

A  FILLIN  is  called  by  zero,  one,  or  more  PROMPTS. 

A  FILLIN  asserts  one  PROPERTY. 

A  FILLIN  displays  one  TEXT. 

A  FILLIN  refers  to  zero,  one,  or  more  XREFs. 

A  FILLIN  contains  one  CONTEXT. 


FLTSTATE 


Fault  State 


This  entity  references  a  list  of  faults  (i.e.  an  ambiguity  group)  that  are 
implicated  in  the  fault  state  and  a  list  of  faults  that  are  "exculpated" 
from  blame  in  the  fault  state.  FLTSTATE  provides  information  necessary  to 
select  the  next  diagnostic  test,  which  may  be  done  explicitly  in  a  decision 
tree  or  by  the  software  in  a  dynamic  model. 


Entity  Relationships: 

A  FLTSTATE  is  identified  by  zero,  one,  or  more  FAULTS. 

A  FLTSTATE  identifies  zero,  one,  or  more  EXPFAULTs. 

A  FLTSTATE  identifies  zero,  one,  or  more  IMPFAULTs. 

A  FLTSTATE  displays  zero  or  one  TEXT. 

A  FLTSTATE  refers  to  zero,  one,  or  more  XREFs. 

A  FLTSTATE  identifies  zero  or  one  TEST. 

A  FLTSTATE  is  identified  by  zero,  one,  or  more  OUTCOMES, 
A  FLTSTATE  contains  one  CONTEXT. 
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FOCUS  Graphic  Focus 

This  entity  references  a  list  of  subgraphics,  within  a  composite  graphic, 
that  are  of  interest  in  a  particular  illustration.  This  could  be  used  to 
indicate  applicable  callout  references. 

Entity  Relationships: 

A  FOCUS  is  specified  by  one  GRAPHIC. 

A  FOCUS  specifies  one  GRPHPRIM  or  GRAPHIC. 


FOLLOWON  Follow-On  Task 

This  entity  references  a  list  of  tasks  that  the  technician  is  required  to 
perform  after  completion  of  the  current  task. 


Entity  Relationships: 

A  FOLLOWON  task  is  referenced  by  one  TASK. 
A  FOLLOWON  task  refers  to  one  TASK. 


GRAPHIC  Graphic  Entity 


GRAPHIC  references  an  entity  used  to  group  graphic  primitives  into  a 
composite  graphic.  It  also  supports  transformations  that  must  be 
performed  on  the  graphic  primitives  to  scale,  rotate,  and  translate  the 
individual  primitives  into  a  composite  image. 


Entity  Relationships: 

A  GRAPHIC  is  displayed  by  zero,  one,  or  more  DESCINFOs. 
A  GRAPHIC  is  displayed  by  zero,  one,  or  more  STEPS. 

A  GRAPHIC  refers  to  zero,  one,  or  more  SUBGRAPHICs. 

A  GRAPHIC  displays  zero  or  one  TEXT. 

A  GRAPHIC  specifies  zero,  one,  or  more  FOCUS. 

A  GRAPHIC  contains  zero,  one,  or  more  GRPHPRIMs . 

A  GRAPHIC  refers  to  zero,  one,  or  more  XREFs. 

A  GRAPHIC  contains  one  CONTEXT. 


GRPHPRIM  Graphic  Primitive 

This  entity  references  a  single  graphic  component  which,  when  combined  with 
other  primitives,  can  become  a  composite  graphic.  A  graphic  primitive 
references  a  file  that  contains  the  detailed  graphic  information  in  the 
form  of  CGM,  IGES,  FAX,  or  DXF  graphic  codes. 

Entity  Relationships: 

A  GRPHPRIM  is  contained  in  one  GRAPHIC. 

A  GRPHPRIM  is  specified  by  zero,  one,  or  more  FOCUS. 

A  GRPHPRIM  displays  zero  or  one  TEXT. 

A  GRPHPRIM  refers  to  zero,  one,  or  more  XREFs. 

A  GRPHPRIM  contains  one  CONTEXT. 
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IMPFAULT  Implicated  Fault 

This  entity  references  a  list  of  faults  that  are  implicated  (i.e. 
suspected)  in  a  particular  fault  state. 

Entity  Relationships: 

An  IMPFAULT  is  identified  by  one  FLTSTATEs . 

An  IMPFAULT  identifies  one  FAULT. 


MAXNTLVL  Maintenance  Level 

This  entity  represents  the  appropriate  maintenance  level  of  repair  of  an 
item,  and  helps  provide  the  correct  information  for  that  level.  Valid 
levels  are:  organizational,  intermediate,  and  depot. 

Entity  Relationships: 

A  MAINTLVL  is  contained  in  one  CONTEXT. 


MENU  Menu  of  User-Selectable  Choices 

MENU  refers  to  a  type  of  prompt  that  is  a  menu  with  multiple  choices .  A 
menu  consists  of  a  question  (i.e.  text),  a  property,  and  a  set  of  possible 
responses  (i.e.  choices).  When  the  user  chooses  a  response,  the  value 
associated  with  the  selected  choice  is  asserted  for  the  value  of  the 
property  associated  with  the  menu. 

Entity  Relationships: 

A  MENU  is  called  by  zero,  one,  or  more  PROMPTS. 

A  MENU  asserts  one  PROPERTY. 

A  MENU  displays  one  TEXT. 

A  MENU  has  one  or  more  CHOICES. 

A  MENU  refers  to  zero,  one,  or  more  XREFs. 

A  MENU  contains  one  CONTEXT. 


NOTE  Note 

This  entity  signifies  additional  information  which  aids  the  technician  in 
completing  the  step  or  task.  A  note  is  used  in  technical  information  to 
emphasize  an  especially  important  procedure  or  condition. 

Entity  Relationships: 

A  NOTE  is  presented  by  zero,  one,  or  more  TASKs. 

A  NOTE  is  presented  by  zero,  one,  or  more  STEPs. 

A  NOTE  displays  one  TEXT. 

A  NOTE  refers  to  zero,  one,  or  more  XREFs. 

A  NOTE  contains  one  CONTEXT. 
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OPERZNFO  Operational  Information 

This  entity  references  procedural  task  information  and  descriptive 
information  required  for  operating  the  system  in  question. 

Entity  Relationships: 

An  OPERINFO  is  referenced  by  zero,  one,  or  more  SYSTEMS. 

An  OPERINFO  refers  to  zero,  one,  or  more  DESCINFOs. 

An  OPERINFO  refers  to  zero,  one,  or  more  TASKS. 

An  OPERINFO  refers  to  zero,  one,  or  more  XREFs . 

An  OPERINFO  contains  one  CONTEXT. 


OUTCOME  Test  Outcome 

This  entity  references  the  fault  states  (both  implicated  and  exculpated 
faults)  known  to  be  true  following  a  specific  test  outcome. 

Entity  Relationships: 

An  OUTCOME  is  produced  by  zero,  one,  or  more  TESTS. 

An  OUTCOME  tests  one  or  more  PRECONDs . 

An  OUTCOME  identifies  one  or  more  FLTSTATEs . 

An  OUTCOME  displays  zero  or  one  TEXTS . 

An  OUTCOME  refers  to  zero,  one,  or  more  XREFs. 

An  OUTCOME  contains  one  CONTEXT. 


PARTBASE  Part  Base  (Supply  Side) 

This  entity  references  the  information  about  a  part  that  does  not  change, 
based  on  the  place  it  is  used  on  the  vehicle.  It  represents  the  supply 
system's  view  of  part  information. 

Entity  Relationships: 

A  PARTBASE  is  identified  by  zero,  one,  or  more  PARTINFOs. 

A  PARTBASE  refers  to  zero,  one,  or  more  XREFs. 


PARTINFO  Part  Information  (Maintainer ' s  View) 

PARTINFO  references  a  part  in  terms  of  its  reference  designator,  which 
categorizes  parts  by  their  place  in  the  system-subsystem  hierarchy.  It 
represents  the  maintainer 's  view  of  part  information. 

Entity  Relationships: 

A  PARTINFO  is  identified  by  zero,  one,  or  more  SYSTEMS. 

A  PARTINFO  is  pointed  to  by  zero,  one,  or  more  FAULTS. 

A  PARTINFO  identifies  one  or  more  PARTBASEs. 

A  PARTINFO  identifies  one  or  more  GRAPHICS. 

A  PARTINFO  refers  to  zero,  one,  or  more  XREFs. 

A  PARTINFO  contains  one  CONTEXT. 
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PERSON  Personnel  Required 

This  entity  references  the  number  and  type  of  personnel  required  to 
complete  a  specific  step  or  procedure. 

Entity  Relationships: 

A  PERSON  is  required  by  zero,  one,  or  more  TASKs. 

A  PERSON  is  required  by  zero,  one,  or  more  STEPs. 

A  PERSON  refers  to  zero,  one,  or  more  XREFs . 

A  PERSON  contains  one  CONTEXT. 


PRECOND  Precondition 

PRECOND  states  a  property /value  condition  or  relation  that  must  be  true  for 
its  associated  data  to  be  applicable  to  the  current  context, 
troubleshooting  outcome,  or  required  condition. 

Entity  Relationships: 

A  PRECOND  is  tested  by  zero,  one,  or  more  OUTCOMES. 

A  PRECOND  tests  by  zero,  one,  or  more  PROPERTY /VALUES . 

A  PRECOND  is  tested  by  zero,  one,  or  more  REQCONDs . 

PROCESS  Software  Process 

This  entity  indicates  an  external  software  process,  whether  it  is  a  file, 
a  1553  MUX  bus  instruction,  a  software  program,  or  some  other  external 
software  process. 

Entity  Relationships: 

A  PROCESS  is  invoked  by  zero,  one,  or  more  DESCINFOs. 

A  PROCESS  is  invoked  by  zero,  one,  or  more  STEPs. 

A  PROCESS  refers  to  zero,  one,  or  more  XREFs. 

A  PROCESS  contains  one  CONTEXT. 


PROMPT  User  Input  Prompt 

This  entity  refers  to  a  fill-in  or  menu  question,  which  the  system  cannot 
assert  itself,  that  requires  input  or  a  decision  from  the  user.  Each 
prompt  is  associated  with  a  property  that  will  be  asserted,  along  with  the 
user's  response  (value),  when  the  prompt  is  answered. 


Entity  Relationships: 

A  PROMPT  is  presented  by  zero,  one,  or  more  DESCINFOs. 
A  PROMPT  is  presented  by  zero,  one,  or  more  STEPs. 

A  PROMPT  points  to  one  FILLIN  or  one  MENU. 

A  PROMPT  displays  zero  or  one  TEXT. 

A  PROMPT  refers  to  zero,  one,  or  more  XREFs. 

A  PROMPT  contains  one  CONTEXT. 
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PROPERTY  Property 

PROPERTY  references  any  text  string  that  defines  a  conditional  situation. 
At  run  time,  PROPERTY /VALUE  pairs  may  be  asserted  or  tested  by  the 
software . 

Entity  Relationships: 

A  PROPERTY  is  asserted  by  zero,  one,  or  more  FILLINs . 

A  PROPERTY  is  asserted  by  zero,  one,  or  more  MENUS. 

A  PROPERTY  has  by  zero,  one,  or  more  PROPERTY /VALUES . 

A  PROPERTY  displays  one  TEXT. 

A  PROPERTY  refers  to  zero  or  one  ELMNTREFs. 


PROPERTY/VALUE  Property-Value  Pair 

This  entity  ties  a  unique  property  to  a  unique  value  to  create  a 
PROPERTY /VALUE  pair  which  may  be  asserted  or  tested  by  the  software. 

Entity  Relationships: 

A  PROPERTY /VALUE  contains  one  PROPERTY. 

A  PROPERTY /VALUE  contains  one  VALUE. 

A  PROPERTY /VALUE  is  tested  by  zero,  one,  or  more  PRECONDs . 

A  PROPERTY /VALUE  is  tested  by  zero,  one,  or  more  ASSERTIONS. 


RECT  Fault  Rectification 

RECT  points  to  the  repair  procedures  necessary  to  fix  an  associated  fault. 
This  entity  also  references  tests,  which  are  usually  checkout  tasks,  to 
verify  that  the  rectification  was  successful.  RECT  also  has  a  fault 
attribute  used  to  identify  all  the  faults  repaired  by  the  rectification. 

Entity  Relationships: 

A  RECT  is  identified  by  zero,  one,  or  more  FAULTS. 

A  RECT  identifies  one  or  more  TASKS. 

A  RECT  identifies  zero,  one,  or  more  TESTs. 

A  RECT  displays  zero  or  one  TEXT. 

A  RECT  refers  to  zero,  one,  or  more  XREFs. 

A  RECT  contains  one  CONTEXT. 


RELEASE  Release  Specification 

This  entity  identifies  the  countries  in  which  the  document  may  be  released. 

Entity  Relationships: 

A  RELEASE  is  contained  in  one  CONTEXT. 


A- 15 


1  Jun  90 


MIL-M-IETMDB 
1  June  1990 


REQCOND  Required  Condition 

This  entity  references  a  list  of  preliminary  conditions  that  must  be 
satisfied  before  performing  a  step  or  step  sequence  (task). 

Entity  Relationships: 

A  REQCOND  is  tested  by  zero,  one,  or  more  TASKS. 

A  REQCOND  is  tested  by  zero,  one,  or  more  STEPS. 

A  REQCOND  tests  zero,  one,  or  more  PRECONDs . 

A  REQCOND  refers  to  zero,  one,  or  more  XREFs . 

A  REQCOND  contains  one  CONTEXT-. 


RESTRICT  Restrictions 

This  entity  represents  any  security  restrictions  that  might  apply  to  an 
entity. 

Entity  Relationships: 

A  RESTRICT  is  contained  in  one  CONTEXT. 


SCILEVEL  Scientific  Level 

This  entity  represents  the  scientific  level  of  an  entity. 
Entity  Relationships: 

A  SCILEVEL  is  contained  in  one  CONTEXT. 


SECURITY  Security  Classification 

This  entity  represents  the  security  level  of  the  information. 

Entity  Relationships: 

A  SECURITY  is  contained  in  one  CONTEXT. 
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STEP  Task  Step 

This  entity  designates  a  procedural  step  within  a  task.  A  STEP  can 
reference  a  number  of  primitive  entities  (see  entity  relationships). 

Entity  Relationships: 

A  STEP  is  contained  in  zero,  one,  or  more  TASKs. 

A  STEP  asserts  zero,  one,  or  more  ASSERTIONS. 

A  STEP  presents  zero,  one,  or  more  TABLES. 

A  STEP  refers  to  zero,  one,  or  more  SUBSTEPs. 

A  STEP  displays  zero,  one,  or  more  GRAPHICS. 

A  STEP  invokes  zero,  one,  or  more  AUDIO  processes. 

A  STEP  invokes  zero,  one,  or  more  VIDEO  processes. 

A  STEP  presents  zero,  one,  or  more  PROMPTS. 

A  STEP  invokes  zero,  one,  or  more  PROCESSes. 

A  STEP  refers  to  zero,  one,  or  more  ANNOTs . 

A  STEP  refers  to  zero,  one,  or  more  XREFs . 

A  STEP  presents  zero,  one,  or  more  WARNINGS. 

A  STEP  presents  zero,  one,  or  more  CAUTIONS. 

A  STEP  presents  zero,  one,  or  more  NOTES. 

A  STEP  reflects  zero,  one,  or  more  VERBS. 

A  STEP  tests  for  zero,  one,  or  more  REQCONDs . 

A  STEP  requires  zero,  one,  or  more  PERSONS. 

A  STEP  requires  zero,  one,  or  more  EQUIPS. 

A  STEP  requires  zero,  one,  or  more  CONSUMs . 

A  STEP  refers  to  one  TEXT. 

A  STEP  contains  one  CONTEXT. 


SUBDESClNFONext  Descriptive  Information 

SUBDESCINFO  establishes  a  sequence  for  descriptive  information  entities. 
This  entity  ties  the  current  descriptive  information  entity  to  the  next 
descriptive  information  entity. 

Entity  Relationships: 

A  SUBDESCINFO  is  referenced  by  one  DESCINFO. 

A  SUBDESCINFO  refers  to  one  DESCINFO. 


SUBGRAPHIC  Next  Graphic 

This  entity  identifies  the  next  higher  view  of  a  graphic  to  enable  the  user 
to  do  a  "locate"  on  the  graphic  to  find  a  piece  of  equipment  on  the 
vehicle. 

Entity  Relationships: 

A  SUBGRAPHIC  is  referenced  by  one  GRAPHIC. 

A  SUBGRAPHIC  refers  to  one  GRAPHIC. 
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SUBSTEP  Next  Step 

A  SUBSTEP  establishes  a  sequence  for  procedural  steps.  This  entity  ties 
the  current  step  entity  to  the  next  step  entity  to  be  displayed. 

Entity  Relationships: 

A  SUBSTEP  is  referenced  by  one  STEP. 

A  SUBSTEP  refers  to  one  STEP. 


SUBSYSTEM  Lower  Level  System 

This  entity  establishes  a  sequence  for  vehicle/system/subsystems.  A 
SUBSYSTEM  ties  the  current  system  entity  to  the  next  system  entity  to  be 
displayed. 

Entity  Relationships: 

SUBSYSTEM  is  referenced  by  one  SYSTEM. 

A  SUBSYSTEM  refers  to  one  SYSTEM. 


SYSTEM  System 

This  entity  identifies  a  vehicle,  system,  subsystem,  or  subassembly  entity 
in  the  equipment  hierarchy.  A  SYSTEM  may  reference  procedural  task 
information,  descriptive  information,  parts  information,  fault  information, 
or  operational  information. 

Entity  Relationships: 

A  SYSTEM  refers  to  zero,  one,  or  more  SUBSYSTEMS. 

A  SYSTEM  refers  to  zero,  one,  or  more  OPERINFOs . 

A  SYSTEM  refers  to  zero,  one,  or  more  DESCINFOs. 

A  SYSTEM  refers  to  zero,  one,  or  more  TASKS. 

A  SYSTEM  refers  to  zero,  one,  or  more  FAULTINFs . 

A  SYSTEM  identifies  zero,  one,  or  more  PARTINFOs. 

A  SYSTEM  refers  to  zero,  one,  or  more  XREFs. 

A  SYSTEM  contains  one  CONTEXT. 


TABLE  Tabular  Information 


This  entity  references  the  components  required  to  construct  a  table  or 
chart . 


Entity  Relationships: 

A  TABLE  is  presented  by  zero,  one,  or  more 
A  TABLE  is  presented  by  zero,  one,  or  more 
A  TABLE  contains  one  or  more  COLHDDEFs. 

A  TABLE  contains  one  or  more  ENTRYs. 

A  TABLE  refers  to  zero,  one,  or  more  XREFs 
A  TABLE  contains  one  CONTEXT. 


DESCINFOs. 
STEPS . 
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TASK  Task 

A  TASK  is  a  set  of  directive  steps  which  make  up  a  specific  maintenance 
procedure.  A  maintenance  procedure  could  be  a  preventive  or  corrective 
maintenance  task.  Preventive  tasks  are  preformed  at  regular  intervals  to 
ensure  that  the  item  or  system  will  continue  to  operate  correctly  and 
safely  (such  as  inspect,  clean,  lubricate,  etc).  Corrective  (or 
unscheduled)  maintenance  procedures  are  performed  when  required  to  repair 
faulty  items  or  systems  that  have  been  identified  by  troubleshooting 
procedures.  A  procedural  task  is  made  up  of  steps,  and  ties  all  text, 
graphics,  messages,  prompts,  and  references  required  to  convey  the  step 
together.  A  TASK  contains  linking  information  necessary  to  link  one  TASK 
to  other  TASKS. 

Entity  Relationships: 

A  TASK  is  referenced  by  zero,  one,  or  more  SYSTEMS. 

A  TASK  is  referenced  by  zero,  one,  or  more  OPERINFOs . 

A  TASK  required  zero,  one,  or  more  PERSONS. 

A  TASK  required  zero,  one,  or  more  EQUIPS. 

A  TASK  required  zero,  one,  or  more  CONSUMs . 

A  TASK  presents  zero,  one,  or  more  WARNINGS. 

A  TASK  presents  zero,  one,  or  more  CAUTIONS. 

A  TASK  presents  zero,  one,  or  more  NOTES. 

A  TASK  refers  to  zero,  one,  or  more  XREFs. 

A  TASK  tests  for  zero,  one,  or  more  REQCONDs . 

A  TASK  contains  one  or  more  STEPS. 

A  TASK  refers  to  zero,  one,  or  more  FOLLOWON  tasks. 

A  TASK  reflects  zero,  one,  or  more  VERBS. 

A  TASK  is  identified  by  zero,  one,  or  more  TESTS. 

A  TASK  is  identified  by  zero,  one,  or  more  RECTs . 

A  TASK  contains  one  CONTEXT. 


TEST  Fault  Isolation  Test 

This  entity  indicates  a  diagnostic  test  that  will  lead  to  outcomes  a  :d 
guide  the  technician  toward  a  rectification  during  troubleshooting. 

Entity  Relationships: 

A  TEST  is  identified  by  zero,  one,  or  more  FAULTINFs . 

A  TEST  is  identified  by  zero,  one,  or  more  FLTSTATEs . 

A  TEST  identifies  one  or  more  TASKS. 

A  TEST  produces  one  or  more  OUTCOMES . 

A  TEST  displays  zero  or  one  TEXT. 

A  TEST  refers  to  zero,  one,  or  more  XREFs. 

A  TEST  is  identified  by  zero,  one,  or  more  RECTs. 

A  TASK  contains  one  CONTEXT. 
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TEXT  Text 

The  TEXT  entity  represents  a  string  of  parsable  character  data.  This  could 
be  a  letter,  number,  word,  sentence,  paragraph,  etc. 

Entity  Relationships: 


TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

DESCINFOs. 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

STEPS . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

FAULTS . 

TEXT 

is 

displayed  by 

zero, 

one , 

or 

more 

FLTSTATEs . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

TESTS . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

OUTCOMES . 

TEXT 

is 

displayed  by 

zero. 

one , 

or 

more 

RECTs . 

TEXT 

refers  to  zero, 

one , 

or  more  : 

XREFs 

• 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

GRAPHICS. 

TEXT 

is 

displayed 

by 

zero. 

one , 

or 

more 

GRPHPRIMs . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

ENTRYs . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

WARNINGS . 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

CAUTIONS. 

TEXT 

is 

displayed 

by 

zero, 

one, 

or 

more 

NOTES . 

TEXT 

is 

displayed 

by 

zero, 

one, 

or 

more 

FILLINs . 

TEXT 

is 

displayed 

by 

zero, 

one. 

or 

more 

PROPERTYS . 

TEXT 

is 

displayed 

by 

zero, 

one, 

or 

more 

MENUS . 

TEXT 

is 

displayed 

by 

zero, 

one. 

or 

more 

CHOICES. 

TEXT 

is 

displayed 

by 

zero, 

one , 

or 

more 

PROMPTS . 

TEXT 

is 

displayed 

by 

zero, 

one, 

or 

more 

VALUES . 

TEXT 

is 

displayed 

by 

zero, 

one, 

or 

more 

ANNOTs . 

TEXT 

contains  one 

CONTEXT. 

TRACK  User  Track  Level  Designation 

This  entity  represents  the  skill  level  (either  Expert  or  Novice) 
appropriate  for  the  information  the  technician  wants /requires  in  traversing 
the  data. 

Entity  Relationships: 

A  TRACK  is  contained  in  one  CONTEXT. 


VALUE  Value 

A  VALUE  is  paired  with  a  specific  PROPERTY  so  the  PROPERTY /VALUE  pair  can 
be  referenced  in  a  menu,  fill-in-the-blank  question,  assertion,  or 
precondition . 

Entity  Relationships: 

A  VALUE  is  contained  in  zero,  one,  or  more  CHOICES. 

A  VALUE  is  contained  in  zero,  one,  or  more  PROPERTY/ VALUES. 

A  VALUE  displays  one  TEXT. 
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VERB  Verb 

This  entity  signifies  a  common  verb  or  action  that  may  be  performed  within 
a  task  or  step  (e.g.,  remove,  replace,  inspect,  adjust,  or  align). 

Entity  Relationships: 

A  VERB  is  reflected  by  zero,  one,  or  more  TASKs. 

A  VERB  is  reflected  by  zero,  one,  or  more  STEPs. 

A  VERB  refers  to  zero,  one,  or  more  XREFs. 

A  VERB  contains  one  CONTEXT. 


VERSION  Version  Number 

This  entity  indicates  the  document  version  of  the  information  to  traverse 
while  performing  maintenance  operations. 

Entity  Relationships: 

A  VERSION  is  contained  in  one  CONTEXT. 


VERSTAT  Verification  Status 

This  entity  indicates  whether  or  not  the  information  has  been  verified. 

Entity  Relationships: 

A  VERSTAT  is  contained  in  one  CONTEXT. 


VIDEO  Video  Process 

This  entity  references  an  external  video  sequence,  whether  it  is  a  file  or 
some  other  external  component. 

Entity  Relationships: 

A  VIDEO  process  is  invoked  by  zero,  one,  or  more  DESCINFOs. 

A  VIDEO  process  is  invoked  by  zero,  one,  or  more  STEPS. 

A  VIDEO  process  refers  to  zero,  one,  or  more  XREFs. 

A  VIDEO  contains  one  CONTEXT. 


WARNING  Warning 

A  WARNING  notifies  the  technician  that  a  task  or  step  may  be  harmful  to 
himself  or  another  human  if  not  properly  performed. 

Entity  Relationships: 

A  WARNING  is  presented  by  zero,  one,  or  more  TASKs. 

A  WARNING  is  presented  by  zero,  one,  or  more  STEPs. 

A  WARNING  displays  one  TEXT. 

A  WARNING  refers  to  zero,  one,  or  more  XREFs. 

A  WARNING  contains  one  CONTEXT. 
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XREF  Cross-Reference 

An  XREF  references  a  relational  link  between  any  two  elements  or  an  entity 
with  a  file  or  database  object. 

Entity  Relationships: 

An  XREF  is  referenced  by  zero,  one,  or  more  SYSTEMS. 

An  XREF  is  referenced  by  zero,  one,  or  more  OPERINFOs. 

An  XREF  is  referenced  by  zero,  one,  or  more  DESCINFOs . 

An  XREF  is  referenced  by  zero,  one,  or  more  TASKS. 

An  XREF  is  referenced  by  zero,  one,  or  more  STEPs. 

An  XREF  is  referenced  by  zero,  one,  or  more  FAULTINFs. 

An  XREF  is  referenced  by  zero,  one,  or  more  FAULTS. 

An  XREF  is  referenced  by  zero,  one,  or  more  FLTSTATEs. 

An  XREF  is  referenced  by  zero,  one,  or  more  TESTs. 

An  XREF  is  referenced  by  zero,  one,  or  more  OUTCOMES. 

An  XREF  is  referenced  by  zero,  one,  or  more  RECTs . 

An  XREF  is  referenced  by  zero,  one,  or  more  PARTBASEs. 

An  XREF  is  referenced  by  zero,  one,  or  more  PARTINFOs . 

An  XREF  is  referenced  by  zero,  one,  or  more  TEXTS. 

An  XREF  is  referenced  by  zero,  one,  or  more  GRAPHICS. 

An  XREF  is  referenced  by  zero,  one,  or  more  GRPHPRIMs. 

An  XREF  is  referenced  by  zero,  one,  or  more  TABLES. 

An  XREF  refers  to  zero  or  one  REFERENCES  OUTSIDE  THE  DATABASE. 

An  XREF  contains  zero,  one,  or  more  ELMNTREFs . 

An  XREF  is  referenced  by  zero,  one,  or  more  WARNINGS. 

An  XREF  is  referenced  by  zero,  one,  or  more  CAUTIONS. 

An  XREF  is  referenced  by  zero,  one,  or  more  NOTEs. 

An  XREF  is  referenced  by  zero,  one,  or  more  FILLINs . 

An  XREF  is  referenced  by  zero,  one,  or  more  MENUS. 

An  XREF  is  referenced  by  zero,  one,  or  more  PROMPTS. 

An  XREF  is  referenced  by  zero,  one,  or  more  REQCONDs . 

An  XREF  is  referenced  by  zero,  one,  or  more  AUDIOS. 

An  XREF  is  referenced  by  zero,  one,  or  more  VIDEOS. 

An  XREF  is  referenced  by  zero,  one,  or  more  PROCESSes. 

An  XREF  is  referenced  by  zero,  one,  or  more  EQUIPS, 

An  XREF  is  referenced  by  zero,  one,  or  more  CGnSUMs. 

An  XREF  is  referenced  by  zero,  one,  or  more  VERBS. 

An  XREF  is  referenced  by  zero,  one,  or  more  ANNOTs. 

An  XREF  is  referenced  by  zero,  one,  or  more  PERSONS. 
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DATA  ELEMENT  DICTIONARY 
SECTION  TWO 
ATTRIBUTE  DEFINITIONS 


ACTION  Maintenance  Fault  Rectification  Action 

Data  Format:  A(5)  Left 

The  ACTION  describes  the  type  of  maintenance  action  required  to  rectify, 
or  fix,  a  fault.  The  action  can  be  a  SWAP,  which  means  it  is  a 
removal/replacement  action,  or  it  can  be  a  MAINT  action,  which  means  it  is 
an  adjustment,  alignment,  or  similar  action. 

Attribute  of:  RECT 


AGENT  Performer  of  Fault  Isolation 

Data  Format:  A(7)  Left 

This  attribute  designates  whether  a  maintenance  action  (e.g.,  a  test  or  a 
rectification  action)  is  performed  by  a  human  or  a  machine. 

Attribute  of:  RECT,  TEST 

CAGE  Commercial  and  Government  Entity 

Data  Format:  A(5)  Fixed 

This  attribute  is  a  five-character  code  assigned  by  the  Defense  Logistics 
Services  Center  (DLSC)  to  the  design  control  activity  or  actual 
manufacturer  of  an  item  contained  in  the  Cataloguing  Handbook  H4/H8  series. 

LSAR:  047  -  Commercial  and  Government  Entity  (CAGE)  Code. 

Attribute  of:  CONSUM,  EQUIP,  PARTBASE 


CODING  Graphics  Codes 

Data  Format:  X(80)  Left 

This  attribute  identifies  the  particular  storage  type  of  the  current 
graphic  file  (e.g.  IGES,  CGM) . 

Attribute  of:  GRPHPRIM 
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Data  Format:  9(4)  Right 

COL  represents  the  specific  column  of  a  table  where  the  current  entry 
belongs . 

Attribute  of :  ENTRY 


COLNUM  Column  of  a  Table 

Data  Format:  9(2)  Right 

This  attribute  indicates  the  column  number  within  the  table  to  which  the 
current  element  refers. 

Attribute  of:  COLHDDEF 


CONTEXT. ID  Effect ivity  Analysis 
Data  Format:  9(15)  Right 

This  attribute  references  the  entity  CONTEXT,  which  is  a  set  of  frequently- 
used  effectivity  attributes  and  a  list  of  user-defined  preconditions  to 
ensure  proper  traversal  of  database  information  to  provide  the  correct 
information  to  the  technician  for  the  current  system  being 
maintained/repaired . 

Attribute  of:  ALTEQUID,  ANNOT,  ASSERTION,  AUDIO,  CAUTION,  CHOICE, 
CODEWORD,  COLHDDEF,  CONFIG,  CONSUM,  DESCINFO,  DIGLYPH,  ELMNTREF ,  ENTRY, 
EQUIP,  EXPFAULT ,  FAULT,  FAULTINF,  FILLIN,  FLTSTATE ,  FOCUS,  FOLLOWON, 
GRAPHIC,  GRPHPRIM,  IMPFAULT,  MAINTLVL,  MENU,  NOTE,  OPERINFO,  OUTCOME, 
PARTINFO,  PERSON,  PROCESS,  PROMPT,  RECT,  RELEASE,  REQCOND,  RESTRICT, 
SCILEVEL,  SECURITY,  STEP,  SUBDESCINFO,  SUBGRAPHIC,  SUBSTEP,  SUBSYSTEM, 
SYSTEM,  TABLE,  TASK,  TEST,  TEXT,  TRACK,  VERB,  VERSION,  VERSTAT,  VIDEO, 
WARNING 


DEFAULT  Default  Fill-in-the-Blank  Response 

Data  Format:  A(80)  Left 

This  attribute  signifies  a  text  string  that  will  be  used  as  the  initial 
entry  in  the  f ill-in-the-blank  form. 

Attribute  of:  FILLIN 
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DEFAULTVAL  Default  Menu  Choice 

Data  Format:  A{1)  Fixed 

This  attribute  indicates  (Y  or  N)  if  a  specific  choice  on  a  menu  is 
considered  to  be  the  default  selection. 

Attribute  of:  CHOICE 


ESTTIME  Estimated  Time  for  Completion 

Data  Format:  9(10)  Right 

The  ESTTIME  indicates  the  amount  of  time,  in  minutes,  required  for  the 
corresponding  task/step  to  be  completed. 

Attribute  of:  STEP,  TASK 


FILE  Data  File 

Data  Format:  X(80)  Left 

This  attribute  represents  the  name  of  an  external  file  which  may  contain 
graphic,  audio,  video,  or  software  information. 

Attribute  of:  AUDIO,  GRPHPRIM,  PROCESS,  VIDEO 


GOVSTD  Government  Standard 

Data  Format:  X(15)  Left 

GOVSTD  signifies  a  document  that  establishes  engineering  and  technical 
requirements  for  processes,  procedures,  practices,  and  methods  that  have 
been  adopted  as  a  standard.  It  also  establishes  requirements  for 
selection,  application,  and  design  criteria  for  materials. 

Attribute  of:  CONSUM 


HCI  Hardness  Critical  Item 

Data  Format:  X ( 1 )  Fixed 

This  attribute  represents  a  code  which  indicates  that  an  item  could  degrade 
system  survivability  in  a  nuclear,  biological,  or  chemically  hostile 
environment  if  hardness  were  not  considered. 

LSAR:  133  -  Hardness  Critical  Item  (HCI) 

Attribute  of:  PARTBASE 
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ICC  Item  Category  Code 
Data  Format:  X(2)  Left 

ICC  signifies  a  code  which  identifies  a  type  of  item,  and  indicates 
categories  into  which  support  and  test  equipment,  spares,  repair  parts, 
etc.  may  be  divided. 

Note:  ICCs  of  "A,"  "B,”  and  "C"  should  not  be  assigned  to  hardware 
items:  these  codes  are  reserved  for  grouping  and  selecting  similar  ICCs 
during  automated  data  processing. 

Peculiar  Support  Equipment  and  Tools  not 
Currently  in  the  DOD  Inventory  (ICC  Group  A): 


Peculiar  Support  Equipment  (Other)  7 

Peculiar  Tools  8 

Peculiar  Test  Equipment  M 

Peculiar  Handling  Equipment  D 

Peculiar  Automatic  Test  Equipment  (ATE)  1 


Common  Support  Equipment  and  Tools  Currently 
in  the  DOD  Inventory  (ICC  Group  B) : 


Common  Support  Equipment  (Other)  H 

Common  Tools  4 

Common  Test  Equipment  5 

Common  Handling  Equipment  6 

Common  Automatic  Test  Equipment  (ATE)  2 
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Common  Support  Equipment  and  Tools  Currently 
in  the  DOD  Inventory  but  not  Assigned 
to  a  Unit /Ship  (ICC  Group  C): 


Common  Support  Equipment  (Other)  G 

Common  Tools  N 

Common  Test  Equipment  P 

Common  Handling  Equipment  R 

Common  Automatic  Test  Equipment  (ATE)  3 

Bulk  Items  Q 

Training  material  not  currently  in  the  DOD  inventory  S 
Training  material  currently  in  the  DOD  inventory  T 

End  Item  W 

Spare  (repairable  support  item)  X 

Repair  part  (a  nonrepairable  consumable  support  Y 

item,  component,  assembly) 

Repair  Parts  Kit  Z 

A  repair  part,  component  or  assembly  that  is  9 

contained  in  a  kit/set 

Tool  Kit/Set  V 

Program  (Embedded  software)  E 

Tech  Manuals  F 

Forms  or  records  J 

Electrostatic  Discharge-Sensitive  Item  K 

Electromagnetic-Sensitive  Item  L 

Facilities  U 

System-Peculiar  Spare  Part  AA 

Maintenance  Significant  Consumable  AB 

Modified  Hand  Tool  AC 

Maintenance  Assist  Module  AD 


LSAR:  159  -  ITEM  CATEGORY  CODE  (ICC) 

Attribute  of:  CONSUM,  EQUIP 


ID  Identifier 

Data  Format:  X(15)  Left 

The  ID  designates  a  unique,  machine-generated  identifier  for  an  element. 

Attribute  of:  ALTEQUID,  ANNOT,  ASSERTION,  AUDIO,  CAUTION,  CHOICE, 

CODEWORD,  COLHDDEF ,  CONFIG,  CONSUM,  CONTEXT,  DESCINFO,  DIGLYPH,  ELMNTREF , 
ENTRY,  EQUIP,  EXPFAULT ,  FAULT,  FAULTINF,  FILLIN,  FLTSTATE ,  FOCUS,  FOLLOWON, 
GRAPHIC,  GRPHPRIM,  IMPFAULT,  MAINTLVL,  MENU,  NOTE,  OPERINFO,  OUTCOME, 
PARTBASE,  PARTINFO,  PERSON,  PRECOND,  PROCESS,  PROMPT,  PROPERTY, 
PROPERTY /VALUE,  RECT,  RELEASE,  REQCOND,  RESTRICT,  SCILEVEL,  SECURITY,  STEP, 
SUBDESCINFO,  SUBGRAPHIC,  SUBSTEP,  SUBSYSTEM,  SYSTEM,  TABLE,  TASK,  TEST, 
TEXT,  TRACK;  VALUE,  VERB,  VERSION,  VERSTAT,  VIDEO,  WARNING,  XREF 
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XNDXNUM  Index  Number 

Data  Format:  X(15)  Left 

This  attribute  represents  the  maintainer's  view  of  part  information.  It 
describes  an  item  by  its  reference  designator  ("refdes"),  which  categorizes 
parts  by  their  place  in  the  system-subsystem  hierarchy. 

Attribute  of:  PARTINFO 


ITEMXD  Item  Id 

Data  Format:  X(10)  Left 

The  ITEMID  represents  the  specific  equipment  item  which  is  associated  to 
the  element  it  falls  under.  It  could  be  a  reference  designator,  social 
security  number,  part  number,  and  so  on,  depending  on  which  element  it 
refers  to. 

Attribute  of:  ANNOT,  AUDIO,  CAUTION,  COLHDDEF ,  CONSUM,  DESCINFO,  ENTRY, 
EQUIP,  FAULT,  FAULTINF,  FILLIN,  FLTSTATE ,  GRAPHIC,  GRPHPRIM,  MENU,  MENU, 
NOTE,  OPERINFO,  OUTCOME,  PARTBASE,  PARTINFO,  PERSON,  PROCESS,  PROMPT,  RECT, 
REQCOND,  STEP,  SYSTEM,  TABLE,  TASK,  TEST,  VERB,  VIDEO,  WARNING 


MFGCODE  Manufacturer's  Code. 

Data  Format:  X(10)  Left 

This  attribute  indicates  the  in-house  code  a  manufacturer  uses  to  represent 
parts . 

Attribute  of:  CONSUM 

MILSPEC  Military  Specification  Number 

Data  Format:  X(10)  Left 

This  attribute  represents  the  exact  specification  for  each  item  bought  by 
the  government. 

Attribute  of:  CONSUM 


A-28 


1  Jun  90 


MIL-M- IETMDB 
1  June  1990 


MXNSXZE  Minimum  Size 

Data  Format:  9(10)  Right 

This  attribute  indicates  the  minimum  size  at  which  a  graphic  must  be 
displayed  to  satisfy  the  technician's  requirements.  The  unit  of  measure 
should  represent  the  size  of  the  image,  in  terms  of  minutes,  of  the  angle 
formed  between  the  user's  eye  and  the  top  and  bottom  of  the  graphic  (the 
arc  which  must  be  subtended  at  the  eye  by  the  graphic)  to  make  the  graphic 
readable  to  the  user. 

Attribute  of:  GRAPHIC,  GRPHPRIM 


MTBF  Mean  Time  Between  Failures 

Data  Format:  9(10)  Right 

This  attribute  signifies,  for  a  particular  interval,  the  total  functional 
life  of  a  population  of  an  item  divided  by  the  total  number  of  failures 
within  the  population  during  the  measurement  interval.  The  definition 
holds  for  time,  rounds,  miles,  events,  or  other  measure-of-life  units. 

LSAR:  204  -  Mean  Time  Between  Failures  (MTBF) 

Attribute  of:  FAULT,  PARTINFO 


NAME  Entity  Name 

Data  Format:  X(80)  Left 

The  NAME  represents  the  textual  name  or  title  of  an  entity. 

Attribute  of:  ANNOT,  AUDIO,  CAUTION,  CODEWORD,  COLHDDEF,  CONFIG,  CONSUM, 

DESCINFO,  DIGLYPH,  ENTRY,  EQUIP,  FAULT,  FAULTINF,  FILLIN,  FLTSTATE , 
GRAPHIC,  GRPHPRIM,  MAINTLVL ,  MENU,  NOTE,  OPERINFO,  OUTCOME,  PARTBASE, 
PARTINFO,  PERSON,  PROCESS,  PROMPT,  RECT,  RELEASE,  REQCOND ,  RESTRICT, 
SCILEVEL,  SECURITY,  STEP,  SYSTEM,  TABLE,  TASK,  TEST,  TRACK,  VERB,  VERSION, 
VERSTAT,  VIDEO,  WARNING 


NOUNID 


Noun  identifier 


Data  Format: 
This  attribute 
Attribute  of: 


X(  80 )  Left 

indicates  a  general  name  of  a  part. 
PARTINFO 
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NOUNTYPE  Noun  Type 

Data  Format:  X(80)  Left 

This  attribute  signifies  more  specific  descriptors  which  differentiate  part 
names . 

Attribute  of:  PARTINFO 


NSN  National  Stock  Number 

Data  Format:  X(20)  Left 

The  NSN  is  a  number,  assigned  under  the  Federal  Cataloguing  Program  and/or 
North  Atlantic  Treaty  Organization  (NATO)  codification  of  equipment  system 
to  each  approved  item  identification,  which  provides  a  unique 
identification  of  an  item  of  supply  within  a  specified  Federal  Supply 
Classification  (FSC).  The  field  consists  of  a  three-character  prefix,  a 
thirteen-character  National  Stock  Number  (NSN),  and  a  four-character  suffix 
code.  For  applicable  codes,  see  DOD  4100. 38-M. 

LSAR:  227  -  National  Stock  Number  and  Related  Data 

Attribute  of:  CONSUM,  EQUIP,  PARTBASE 


OP  Operator 

Data  Format:  A ( 3 )  Left 

This  attribute  signifies  the  operator  within  a  comparison  between  a 
property  and  a  value.  Some  examples  are:  EQ  (equal),  LE  (less  than  or 
equal),  GT  (greater  than),  NE  (not  equal). 

Attribute  of:  PRECOND 
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OPERABILITY  Operability  Code 

Data  Format:  X(l)  Fixed 

The  OPERABILITY  is  a  code  used  to  indicate  the  operational  status  and 
mission  readiness  of  the  item  during  the  maintenance  task.  Allowable 
values  are: 


Full  Mission-Capable:  performance  of  the  maintenance  C 
task  does  not  degrade  any  mission  capability. 

Partial  Mission-Capable:  performance  of  the  D 

maintenance  task  degrades  the  mission  capability  of 
the  system,  but  can  perform  at  least  one  mission. 

System  Inoperable  During  Equipment  Maintenance:  A 

system  is  not  available  to  periorm  all  normal 
operations . 

System  Operable  During  Equipment  Maintenance:  system  B 
is  available  to  perform  normal  operations. 

Not  Mission-Capable:  system  cannot  perform  any  E 

missions . 


Off-Equipment  Maintenance:  task  is  performed  after  G 
the  item  under  analysis  has  been  removed  from  the 
system. 

Turnaround:  task  occurs  during  normal  turnaround  F 

operations,  and  does  not  affect  the  operability  of 
the  system. 

LSAR:  374  -  Part  of  Task  Code 

Attribute  of :  TASK 


PARTNUM  Part  Number/Reference  Number 

Data  Format:  X<32)  Left 

PARTNUM  signifies  any  number,  other  than  a  government  activity  stock 
number,  used  to  identify  an  item  of  production  or  supply. 

LSAR:  302  -  Reference  Number 

Attribute  of:  PARTBASE 
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PENPATT  Pen  Pattern 

Data  Format:  X(10)  Left 

This  attribute  represents  the  bit-map  pattern  to  be  used  as  the  pen  for 
drawing  lines,  points,  etc.  for  a  particular  graphic. 

Attribute  Of:  GRAPHIC,  GRPHPRIM 

PENSHAPE  Pen  Shape 

Data  Format:  X(10)  Left 

This  attribute  indicates  the  boundary  shape  for  the  pen  for  drawing  lines, 
points,  etc.  for  a  particular  graphic. 

Attribute  Of:  GRAPHIC,  GRPHPRIM 

QUANTITY  Quantity 

Data  Format:  9(10)  Right 

The  QUANTITY  signifies  the  amount  of  the  appropriate  corsumable,  equipment, 
or  people  required  for  the  associated  task/step. 

Attribute  of:  CONSUM,  EQUIP,  PERSON 

RANGE  Range  of  Values 

Data  Format:  X(80)  Left 

This  attribute  represents  the  boundaries  for  valid  choices  or  outcomes, 
according  to  the  element  containing  the  range. 

Attribute  of:  FILLIN,  TEST 

REFDES  Reference  Designator 

Data  Format:  X(10)  Left 

The  REFDES  is  an  identifier  assigned  according  a  numbering  scheme  for 
parts  of  a  system  which  reflects  the  hierarchical  assembly  of  the  system. 

Attribute  of:  PARTINFO 
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REPLVL  Replenishment  Level 

Data  Format:  X(10)  Left 

This  attribute  represents  the  minimum  quantity  of  a  part  in  stock  that  will 
trigger  a  reorder  or  stock  action. 

Attribute  of:  PARTINFO 

ROW  Tabular  Row 

Data  Format:  9(10)  Right 

This  attribute  indicates  a  particular  row  in  a  table. 

Attribute  of:  ENTRY 


SELECT  Number  of  Selections  on  a  Menu 

Data  Format:  A(l)  Fixed 

This  attribute  represents  the  number  of  choices  which  may  be  selected  from 
a  menu  element,  either  single  (S)  selection  or  multiple  (M)  selection. 

Attribute  of:  MENU 

SEQUENCE  Entity  Sequencer 

Data  Format:  9(3)  Right 

This  attribute  identifies  the  sequence  in  which  particular  database 
entities  should  be  presented  in  an  IETM. 

Attribute  Of:  FOLLOWON,  SUBDESCINFO,  SUBGRAPHIC,  SUBSTEP,  SUBSYSTEM 
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SERVZCEDES  Service  Designator  Code 
Data  Format:  X(l)  Fixed 

The  SERVICEDES  is  a  single-position  code  identifying  the  military  service 
or  nonznilitary  major  governmental  agency  having  jurisdiction  over,  or 
executive  management  responsibility  for,  the  acquisition.  Allowable  values 
are : 


Army  A 

Air  Force  F 

Marine  Corps  M 

Navy  N 

Coast  Guard  Y 

All  Military  X 

Federal  Aviation  Administration  T 
FAA/All  Military  J 

National  Security  Agency  S 

Other  0 


LSAR:  334  -  SERVICE  DESIGNATOR  CODE 

Attribute  of:  TASK 


SMR  Source,  Maintenance,  Recovery  Code 

Data  Format:  X(6)  Left 

SMR  codes  are  alphabetic  or  alphanumeric  symbols  used  at  the  time  of 
provisioning  to  indicate  the  source  of  supply  of  an  item,  its  maintenance 
implications,  and  its  recoverability  characteristics.  The  provisioning 
activity  may  require  the  contractor  to  recommend  these  codes.  Approved 
codes  are  defined  in:  AR  700-82,  OPNAVINST  4410.2,  AFR  66-45,  MCO  4400.120, 
and  DSAR  4100.6. 

LSAR:  344  -  SOURCE,  MAINTENANCE  AND  RECOVERABILITY  CODE  (SMR) 

Attribute  of:  PARTBASE 


START  Starting  Point  in  a  Graphics  File 

Data  Format:  X(15)  Left 

This  attribute  identifies  a  location  within  a  graphic  file  where  the 
presentation  system  should  start  reading  graphic  codes  for  the  specific 
graphic  being  presented. 

Attribute  of:  GRPHPRIM 
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STOP  Stopping  Point  in  a  Graphics  File 

Data  Format:  X(15)  Left 

This  attribute  specifies  a  location  within  a  graphic  file  where  the 
presentation  system  should  stop  reading  graphic  codes  for  the  specific 
graphic  being  presented. 

Attribute  of:  GRPHPRIM 


TEXT  Textual  Information 

Data  Format:  Narrative 

The  TEXT  attribute  indicates  a  text  string  of  parsable  character  data. 
This  could  consist  of  numbers,  words,  sentences,  paragraphs,  etc. 

Attribute  of:  TEXT 


TEXT. ZD  Text  Entity  Identifier 

Data  Format:  X(15)  Left 

This  attribute  identifies  a  specific  text  string  (entity)  that  is 
applicable  to  the  current  entity. 

Attribute  of:  ANNOT,  CAUTION,  CHOICE,  MENU,  NOTE,  PROPERTY,  STEP,  VALUE, 

WARNING 


TITLE  Text  Title 

Data  Format:  Narrative 

The  TITLE  represents  parsable  character  data  which  may  be  used  to  title 
text  or  descriptive  information. 

Attribute  of:  DESCINFO,  TEXT 

TRANSFRM  Transformation  Matrix 

Data  Format :  9(9)  Right 

This  attribute  signifies  a  transformation  matrix  which  specifies  coordinate 
translations,  scaling,  or  reflection  and  rotations  in  terms  of  homogenous 
coordinates . 

Attribute  of:  GRAPHIC,  GRPHPRIM 
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TYPE  Entity  Type 
Data  Format:  X(80)  Left 

The  TYPE  attribute  represents  a  unique  quality  about  an  element.  The 
appropriate  values  for  each  entity  shall  be  determined  by  the  procuring 
agency. 

Attribute  of:  ANNOT,  AUDIO,  CAUTION,  CODEWORD,  COLHDDEF,  CONFIG,  CONSUM, 
DESCINFO,  DIGLYPH,  ENTRY,  EQUIP,  EXPFAULT,  FAULT,  FAULTINF,  FILLIN,  FILLIN, 
FILLIN,  FLTSTATE ,  FOLLOWON,  GRAPHIC,  GRPHPRIM,  IMPFAULT,  MAINTLVL ,  MENU, 
NOTE,  OPERINFO,  OUTCOME,  PARTBASE,  PARTINFO,  PERSON,  PROCESS,  PROMPT,  RECT, 
RELEASE,  REQCOND,  RESTRICT,  SCILEVEL,  SECURITY,  STEP,  SYSTEM,  TABLE,  TASK, 
TEST,  TRACK,  VERB,  VERSION,  VERSTAT,  VIDEO,  WARNING 


UNXTMEASUREUnit  of  Measure 

Data  Format:  X(15)  Left 

This  attribute  identifies  the  type  of  unit  measurement  used  to  quantify  the 
number  of  consumables  needed  for  the  current  application. 

Attribute  of:  CONSUM 

UNITSPER  Units  per  Assembly,  System,  etc. 

Data  Format:  X(10)  Left 

This  attribute  Represents  the  number  of  units  required  per  assembly  of  a 
system  or  component. 

Attribute  of :  PARTINFO 

USABLON  Usable -On  Code 

Data  Format:  X(10)  Left 

This  attribute  identifies  the  different  configurations  in  which  a  part  or 
assembly  may  appear  within  a  system  or  vehicle. 

Attribute  of:  PARTINFO 


A-36 


1  Jun  $0 


MIL-M- IETMDB 
1  June  1990 


USER  User  Identifier 

Data  Format:  X(10)  Left 

USER  represents  a  user  identification  attribute  for  annotations  added  by 
the  user  to  the  data. 

Attribute  of:  ANNOT 

WEIGHT  Fault  Probability 

Data  Format:  9(10)  Right 

This  attribute  represents  a  probability  associated  with  a  given  fault 
within  a  list  of  faults  in  a  fault  state. 

Attribute  of:  FLTSTATE 

WINDOW  Graphic  Window 

Data  Format:  9(20)  Right 

The  WINDOW  attribute  indicates  the  subrectangle  within  a  graphic  which 
should  be  displayed  in  those  cases  where  the  author  wishes  to  display  only 
a  portion  of  a  large  graphic  to  the  user. 

Attribute  of:  GRAPHIC,  GRPHPRIM 


WRA  OR  LRU  Weapon  Replaceable  Assembly 

Line  Replaceable  Unit 

Data  Format:  X(l)  Fixed 

This  attribute  signifies  an  essential  support  item  that  is  removed  and 
replaced  at  field  level  to  restore  the  end  item  to  its  operationally  ready 
condition.  Conversely,  a  non-WRA  is  a  part,  component,  or  assembly  used 
in  the  repair  of  a  WRA  when  the  WRA  has  failed  and  has  been  removed  from 
the  end  item  for  repair.  Allowable  values  are: 

Item  is  a  WRA /LRU  Y 

Item  is  not  a  WRA/LRU  N 

Attribute  of :  PARTINFO 
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XREFZD  External  Reference  Identifier 

Data  Formats  X(80)  Left 

The  XREFID  identifies  a  reference  that  is  not  contained  in  the  database. 
Attribute  of:  XREF 
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APPENDIX  B 

IDEFlx  REPRESENTATION  OF  REVI SABLE  IETM  DATABASE 


1.0  INTRODUCTION. 

Appendix  B  contains  an  IDEFlx  representation  of  revisable,  format-free 
technical  information.  IDEFlx  is  a  formal  data  modeling  methodology 
consisting  primarily  of  graphic  representations.  This  appendix  identifies 
the  entities  (see  paragraph  2.1)  and  attributes  (see  paragraph  2.3)  that 
exist  in  technical  information,  and  depicts  the  relationships  these 
entities  have  with  one  another.  This  design  is  not  intended  to  represent 
a  physical  database  implementation. 

2.0  BASIC  COMPONENTS  OF  IDEFlx. 

The  basic  components  of  the  IDEFlx  design  methodology  are  explained  in  the 
subsequent  paragraphs.  Figure  2.0  contains  a  graphic  representation  of  the 
information . 

2.1  ENTITIES. 

An  entity  is  an  object  about  which  information  or  facts  are  kept.  An 
entity  may  be  a  real,  physical  object,  such  as  an  employee  or  a  machine; 
or  it  may  be  an  abstract  object,  such  as  a  schedule  or  event.  Entities  are 
represented  as  boxes  on  IDEFlx  charts.  The  name  of  the  entity  is  shown 
above  the  box.  Section  One  of  Appendix  A  of  the  Data  Element  Dictionary 
contains  a  definition  for  each  entity  in  the  model. 

2.1.1  Parent  Entities. 

A  parent  entity  is  an  entity  that  does  not  depend  upon  any  other  entity  for 
its  existence.  A  parent  entity  may  have  one  or  more  child  entities  (see 
2.1.2).  A  parent  entity  is  represented  in  IDEFlx  as  a  square-cornered  box. 


2.1.2  Child  Entities. 

A  child  entity  is  dependent  for  its  existence  upon  its  parent.  When  the 
child  has  more  than  one  parent,  its  existence  is  dependent  upon  all  of  its 
parents;  that  is,  no  instance  of  the  child  entity  may  occur  without  a 
related  instance  of  each  of  its  parents.  A  child  entity  is  represented  in 
IDEFlx  as  a  rounded  box. 


2.2  RELATIONSHIPS  BETWEEN  ENTITIES. 

A  relationship  establishes  the  fact  that  an  entity  is  paired  with  another 
entity  in  some  manner.  Relationships  are  indicated  by  lines  and  dots 
between  entities. 
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2.2.1  Cardinality  of  Relationships. 

In  a  refined  IDEFlx  model  (see  paragraph  3.1),  most  relationships  between 
entities  are  of  the  type  one  entity  to  zero,  one,  or  many  entities.  This 
is  shown  as  a  line  connected  to  the  entity  that  occurs  once,  with  a  dot  on 

the  end  of  the  line  next  to  the  entity  that  occurs  zero,  one,  or  many 

times.  A  letter  or  number  next  to  the  dot  gives  more  specific  information 
about  the  cardinality,  as  follows: 

Z  -  Zero  or  One 

P  -  One  or  Many 

n  -  A  Specific  Quantity  (n). 

2.2.2  Relationship  Labels. 

Each  relationship  line  in  IDEFlx  is  labeled  with  text  describing  the 
relationship  between  the  two  entities.  Relationships  between  entities  are 
read  from  the  parent  entity  toward  the  child  entity. 

2.2.3  Dependent  Relationships. 

When  one  child  entity  depends  upon  the  existence  of  the  parent  entity,  the 
relationship  line  between  the  two  is  displayed  as  a  solid  line. 

2.2.4  Non-Dependent  Relationships . 

When  two  entities  are  related  but  do  not  depend  upon  the  existence  of  each 
other,  the  relationship  is  displayed  as  a  dashed  line. 

2.2.5  Discriminators . 

When  multiple  entities  have  common  attributes,  a  relationship  between  a 
generalization  entity  and  its  subentities  is  created.  Generalization 
entities  contain  common  attributes.  Subentities  branch  off  the 
generalization  entity,  based  upon  the  value  of  a  discriminator.  A 
discriminator  is  an  attribute  of  the  generalization  entity.  For  example, 
a  PROMPT  may  be  a  MENU  or  it  may  be  a  textual  FILLIN;  the  determination  is 
made  based  upon  the  value  of  the  TYPE  attribute.  A  discriminator  is 
represented  as  an  open  circle  on  the  relationship  line.  Keys  (see 
paragraph  2.3.1)  of  the  subentities  are  exactly  the  same  as  the  keys  of  the 
generalization  entity. 

2 . 3  ATTRIBUTES . 

An  attribute  of  an  entity  is  data  that  represents  a  property  or 
characteristic  of  the  entity.  An  attribute  of  an  entity  must  occur  only 
once  for  an  instance  of  the  entity,  and  must  always  apply  to  an  instance 
of  an  entity.  If  an  attribute  value  is  not  always  applicable  or  not  always 
known,  then  it  is  not  an  attribute.  Rather,  it  is  a  separate  entity,  with 
a  relationship  cardinality  of  "Z"  (zero  or  one).  Section  Two  of  Appendix 
A  of  the  Data  Element  Dictionary  contains  definitions  for  each  of  the 
attributes  in  the  model. 

2.3.1  Key  Attributes. 
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A  key  attribute  is  an  attribute  or  group  of  attributes  that  uniquely 
identify  one  particular  occurrence  on  an  entity.  Attributes  above  the  line 
in  the  entity  box  form  the  entity  key. 

2.3.2  Foreign  Keys. 

The  keys  of  each  parent  entity  migrate  through  the  relationship  to  each 
child  entity.  The  key  may  migrate  to  the  child  either  as  part  of  the  key 
of  the  child  or  as  a  non-key  attribute  of  the  child,  depending  upon  whether 
or  not  the  key  of  the  parent  is  required  to  uniquely  identify  an  instance 
of  the  child.  The  migrated  key  is  identified  as  a  "foreign  key”  in  the 
child  by  putting  (FK)  at  the  end  of  the  attribute. 

2.3.3  Non-Key  Attributes . 

Each  non-key  attribute  has  exactly  one  value  for  each  instance  of  the 
entity.  Different  instances  of  the  entity  may  have  identical  values  for 
non-key  attributes.  Non-key  attributes  are  listed  below  the  line  in  the 
entity  box. 


3.0  NON-IDEFlx  FEATURES  OF  APPENDIX  B. 

3.1  UNREFINED  XDEFlx  MODEL. 

This  appendix  contains  an  unrefined  IDEFlx  model.  A  refined  version  of 
IDEFlx  would  eliminate  all  "many-to-many"  relationships  between  entities. 
(An  example  of  a  "many-to-many"  relationship  is  "Many  different  procedural 
STEPS  could  display  many  different  WARNINGS.")  To  refine  these 
relationships,  new  entities  (intersection  entities)  would  have  to  be 
introduced  to  the  model.  An  intersection  entity  would  be  a  child  entity 
of  the  two  entities  that  had  the  "many-to-many"  relationship  between  them. 
This  intersection  entity  would  inherit  the  keys  of  each  of  its  parents. 
The  refining  of  an  IDEFlx  model  is  a  physical  database  implementation 
issue,  which  will  not  be  addressed  in  this  appendix.  Therefore,  "many-to- 
many"  relationships  are  present  in  this  appendix. 

3.2  ENTITY  CHART  NUMBERS. 

All  entities  that  occur  on  more  than  one  chart  have  a  list  of  applicable 
chart  numbers  under  the  element.  The  circled  number  indicates  the  chart 
that  gives  the  most  complete  description  of  the  entity.  Chart  numbers  for 
each  entity  are  provided  with  the  entity  definitions  in  Part  One  of 
Appendix  A  of  the  Data  Element  Dictionary. 
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< ! DOCTYPE  techinfo  [ 

cl——************************************************************* 

Content  Data  Model  (CDM) 

Version  5.2  5/29/90  DRAFT 

This  document  is  an  SGML  Document  Type  Definition  (DTD)  which 
describes  the  logical  structure  for  a  database  of  technical 
information.  This  version  is  a  working  draft  which  is  still  under 
development  by  the  Air  Force  Human  Resources  Laboratory  (AFHRL/LRC) 
at  Wright  Patterson  AFB. 

*************************************************ii*******iiir**it*——y 
<!  — it************************************************************ 

Entity  Declarations 

These  entity  declarations  define  abbreviations  for  a  set  of 
frequently  used  attributes:  “id,"  "refid".  The  "%ids"  entity 
declaration  defines  an  abbreviation  for  two  element  identifiers 
("id"  and  "refid").  These  identifiers  are  machine  generated 
symbols  used  to  identify  data  elements  in  the  database.  These 
identifiers  are  not  intended  to  be  human  readable  names,  but  only 
machine  readable  pointers  or  references.  Most  elements  in  the  CDM 
have  both  a  unique  identifier  ("id")  and  a  non-unique  reference 
identifier  ("refid") .  The  reference  identifier  ("refid")  is  used 
by  elements  to  refer  or  "point"  to  other  elements.  For  example, 
a  "task"  element  may  refer  to  a  list  of  "step"  elements,  or  a 
"system"  element  may  refer  to  a  list  of  "subassembly"  elements. 
Since  the  reference  id  ("refid")  is  not  unique,  it  may  refer 
to  several  elements  in  the  database.  These  referenced  elements 
will  have  different  "context"  (such  as  version  number  or  security 
level)  which  will  be  used  to  determine  which  unique  element  is 
appropriate  for  a  particular  situation.  Since  SGML  requires  that 
all  "ID"  attributes  be  unique,  an  "ID"  attribute  cannot  be  used  as 
the  reference  id  ("refid") .  Instead,  "refid"  is  defined  as  a 
NMTOKEN. 

The  two  entities  "%refid"  and  "%refids"  are  defined  only  to  improve 
readability.  They  let  the  reader  know  that  an  attribute's  value 
is  meant  to  be  a  reference  identifier  (i.e.,  a  NMTOKEN  specifying 
some  element's  "refid").  These  two  entities,  "%refid"  and 
"%refids,"  are  used  throughout  the  CDM  whenever  a  reference  is 
intended.  This  DTD  also  follows  the  convention  that  the  attribute 
name  of  any  "%refid"  attribute  is  the  same  as  the  element  name  to 
which  it  is  referring.  For  example,  the  "system"  element  has  an 
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attribute  named  "task"  which  is  a  "%refids"  list  intended  to 
contain  only  valid  "refids"  to  "task"  elements.  There  is  one 
notable  exception  to  this  rule.  In  some  cases  an  "elmntref" 
attribute  is  defined  which  is  intended  to  be  a  reference  to  any 
element  type. 


<! ENTITY 

<! ENTITY 
<! ENTITY 


%  ids  "id  ID  # REQUIRED 

refid  NMTOKEN  #PEQUIRED"> 

%  refid  "NMT0KEN"> 


%  refids  "NMT0KENS"> 


Notation  Declarations 

The  following  notations  define  external  references  to  "public" 
graphics  standards  used  in  the  CDM.  The  specified  abbreviations 
(cgmbin,  cgmclear,  cgmchar,  fax,  iges,  dxf,  gks)  are  used  by  the 
element  "graphprm"  to  specify  the  type  of  graphic  representation 
used  to  encode  a  particular  graphic  primitive. 

*******»*******************************************************——> 

<! NOTATION  cgmbin  PUBLIC  "ISO  8632/2//NOTATION  Binary 
encoding//EN"> 

<! NOTATION  cgmchar  PUBLIC  "ISO  8632/2//NOTATION  Character 

encoding//EN" > 

<! NOTATION  cgmclear  PUBLIC  "ISO  8632/2//NOTATION  Clear  text 
encoding//EN"> 

<! NOTATION  fax  PUBLIC  "-//USA-DOD//NOTATION  CCITT  Group  4 
Facsimile//EN"> 

< ! NOTATION  iges  PUBLIC  " -//USA-DOD//NOTATION  Initial  Graphics 
Exchange  Specif ication//EN"> 

<! NOTATION  dxf  PUBLIC  "-//USA-DOD//NOTATION  DXF  Encoding//EN" 
> 

<! NOTATION  gks  PUBLIC  "-//USA-DOD//NOTATION  Graphics  Kernel 
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System//EN"  >  * 


< i _ ************************************************************* 

CDM  Content 

"Techinfo"  is  the  top  element  of  the  CDM  .  Its  content  model  is 
a  long  list  of  elements  (vehicle*,  system*,  ...  )  which  comprise 
the  raw  data  "records"  or  "tables"  for  the  CDM  data  base.  The 
first  "system"  element  in  the  data  base  is  the-  root  or  top  level 
item  in  the  hierarchy. 

************************************************************** — > 

<! ELEMENT  techinfo  -  -  (  system*,  operinfo*,  descinfo*, 

task*,  step*, 

reqcond*,  person*,  equip*,  consum*,  verb*, 

warning*,  caution*,  note*,  annot*, 

partinfo*,  partbase*,  faultinf*  , 

test*,  outcome*,  fltstate*,  fault*,  rect*, 

text*,  title*,  dictitem*,  xref*,  table*,  colhddef*, 

entry*,  list*,  graphic*,  grphprim*, 

video*,  audio*,  process*, 

prompt*,  fillin*,  menu*,  choice*,  context*, 
assertion*,  precond*,  property*,  value*  )> 

< ! ATTLIST  techinfo  %ids; 

system  %refid;  #REQUIRED> 


<! — ************************************************************ 

Vehicle  -  System  -  Subsystem  Hierarchy 

The  CDM  specifies  a  hierarchically  organized  data  base  of  technical 
information  for  a  weapon  system.  The  main  hierarchy  of  the  data 
base  parallels  the  equipment  hierarchy  of  the  weapon  system.  This 
is  normally  represented  as  a  vehicle  -  system  -  subsystem  - 
subassembly  hierarchy  in  AF  Technical  Orders.  That  hierarchy  is 
represented  in  the  CDM  by  the  "system"  element  specified  below. 
Here  "system"  is  used  in  its  most  generic  sense,  meaning  any 
component  or  item  in  the  equipment  hierarchy.  A  "system"  could 
represent  the  vehicle,  an  aircraft  system,  subsystem,  or 
subassembly. 

At  any  level  in  this  hierarchy  (vehicle,  system,  or  subassembly) 
elements  may  reference  associated  information.  They  may  reference 
procedural  task  information  (  "task") ,  descriptive  information 
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("desc"),  parts  information  ("partinfo")  ,  fault  information 
("faultinf") ,  or  operational  information  ("operinfo") .  This 
information  should  be  attached  to  the  level  where  it  is  most 
appropriate.  For  example,  vehicle  towing  procedures  should  be 
referenced  at  the  "vehicle"  level.  The  removal  task  for  a  circuit 
card  in  the  radar  should  be  referenced  at  the  radar  "system"  level. 


The  "system"  element,  like  most  elements  in  the  CDM,  have  a  set  of 
attributes  ("name,"  "type,"  "itemid,"  and  "xrefs")  which  describe 
the  nature  of  the  element's  content.  These  include  attributes 
defining  the  element's  "name"  and  "type".  There  is  also  an 
"itemid"  attribute  used  to  indicate  which  piece  of  equipment  (or 
"item")  is  related  to  the  information  element.  The  "itemid"  could 
be  a  reference  designator,  a  SSSN  number,  a  part  number,  etc., 
depending  on  the  item  of  interest.  There  is  also  an  attribute 
"xref"  which  defines  relational  links  between  the  element  and  other 
elements  in  the  data  base.  An  "xref"  specifies  the  reference 
identifier  for  a  related  element  and  the  type  of  relation  being 
specified. 


<! ELEMENT  system 
<  J  ATTLIST  system 
name 
type 
itemid 
xref 
system 
operinfo 
descinfo 
task 
partinfo 
faultinf 
context 


-  o  EMPTY  > 

%ids; 

CDATA 

#IMPLIED 

CDATA 

♦ IMPLIED 

CDATA 

# IMPLIED 

IDREFS 

# IMPLIED 

% re fids; 

♦ IMPLIED 

% ref ids; 

♦IMPLIED 

%refids; 

♦IMPLIED 

%ref ids; 

♦IMPLIED 

%refids; 

♦IMPLIED 

% re fids ; 

♦IMPLIED 

%ref ids; 

♦IMPLIED> 

Operational  Information 


************************************************************** _ > 

<! ELEMENT  operinfo  -  o  EMPTY  > 

<! ATTLIST  operinfo  %ids; 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 
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itemid 

xref 

descinfo 

task 

context 


CDATA 
IDREFS 
% re fids; 
% re fids ; 
% re fids ; 


# IMPLIED 
I IMPLIED 
# IMPLIED 
# IMPLIED 

#IMPLIED> 


< i — ************************************************************ 

Descriptive  Information 

The  element  "descinfo"  is  used  to  define  general  purpose, 
non-procedural,  narrative  information  such  as  theory  of  operation, 
schematics,  wiring  diagrams,  etc.  "Descinfo"  is  a  very  flexible, 
general  purpose  information  node.  It  can  be  used  to  describe  any 
arbitrary,  hierarchical  hypertext-like  node  containing 
sub-paragraphs  ("descinfo"),  data  ("text,"  "table,"  "graphic," 
"annot,"  "audio,"  "video,"  "process"),  user  interaction 
instructions  ("prompt") ,  and  assertion  properties  ("assertion") 
which  are  asserted  whenever  the  "descinfo"  is  read. 

*************************************************************——> 

<! ELEMENT  descinfo  -  O  EMPTY  > 


< ! ATTLIST  descinfo 

%  ids  ; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

assertion 

IDREFS 

# IMPLIED 

descinfo 

%refids ; 

# IMPLIED 

text 

%ref id; 

# Implied 

table 

%refids; 

# IMPLIED 

graphic 

%ref ids ; 

1 IMPLIED 

audio 

%refids; 

IIMPLIED 

video 

% re fids; 

# IMPLIED 

process 

%refids ; 

IIMPLIED 

annot 

%refids ; 

IIMPLIED 

prompt 

% re fids; 

IIMPLIED 

context 

%refids; 

|IMPLIED> 

<i -.************************************************************* 

Task  Information 

The  elements  "task,"  and  "step"  define  a  maintenance  task  or 
procedure.  A  "task"  consists  of  a  set  of  input  conditions, 
a  list  of  steps  ("step"),  a  list  of  follow-on  tasks  ("followon") , 
and  the  attributes  estimated  time  ("esttime")  and  action  describing 
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"verb".  The  elements  "reqcond"  (required  conditions),  "person" 
(personnel  required) ,  "equip"  (equipment  required) ,  "consum" 
(consumables) ,  and  "verb"  describe  the  input  conditions  referred 
to  by  "step".  The  additional  elements  "warning,"  "caution,"  "note," 
and  "annot"  (user  annotations)  are  referenced  by  "step". 

********************★**************************************— — > 


task  -  o 

EMPTY  > 

task 

%ids ; 

step 

%refids  ? 

♦REQUIRED 

name 

CDATA 

IIMPLIED 

type 

CDATA 

1 IMPLIED 

itemid 

CDATA 

IIMPLIED 

operability 

CDATA 

I IMPLIED 

servicedes 

CDATA 

# IMPLIED 

xref 

IDREFS 

IIMPLIED 

esttime 

NUTOKENS 

IIMPLIED 

verb 

%refids; 

IIMPLIED 

reqcond 

% re fids; 

IIMPLIED 

person 

trefids; 

IIMPLIED 

equip 

%refids; 

IIMPLIED 

consum 

% re fids ; 

IIMPLIED 

warning 

%refids; 

IIMPLIED 

caution 

% re fids; 

IIMPLIED 

note 

%refids; 

IIMPLIED 

followon 

%refids; 

IIMPLIED 

context 

%refids; 

|IMPLIED> 

step  -  o 

EMPTY  > 

step 

%ids; 

text 

%refid; 

♦REQUIRED 

name 

CDATA 

IIMPLIED 

type 

CDATA 

IIMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

esttime 

NUTOKENS 

IIMPLIED 

assertion 

IDREFS 

IIMPLIED 

step 

%refids; 

IIMPLIED 

table 

%ref ids ; 

IIMPLIED 

graphic 

%refids; 

IIMPLIED 

audio 

%refids ; 

IIMPLIED 

video 

%refids ; 

IIMPLIED 

process 

%refids; 

IIMPLIED 

annot 

% re fids ; 

IIMPLIED 

prompt 

% re fids; 

IIMPLIED 

warning 

%refids; 

IIMPLIED 

caution 

% re fids; 

IIMPLIED 
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note- 

%ref ids ; 

# IMPLIED 

verb 

%ref ids; 

# IMPLIED 

reqcond 

%refids; 

# IMPLIED 

person 

%refids; 

# IMPLIED 

equip 

% re fids; 

# IMPLIED 

consum 

% re fids ; 

♦ IMPLIED 

context 

%refids ; 

♦IMPLIED> 

<! ELEMENT  reqcond 
< ! ATTLIST  reqcond 

-  o 
%ids; 

EMPTY  > 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

♦ IMPLIED 

xref 

IDREFS 

# IMPLIED 

precond 

IDREFS 

# IMPLIED 

elmntref 

%ref ids 

;  ♦ IMPLIED 

context 

%ref ids 

;  #IMPLIED> 

<! ELEMENT  person 

-  o 

EMPTY  > 

<! ATTLIST  person 

%ids ; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

context 

%ref ids 

;  #IMPLIED> 

<! ELEMENT  equip 

-  o  EMPTY  > 

< I ATTLIST  equip 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

♦IMPLIED 

nsn 

CDATA 

# IMPLIED 

cage 

CDATA 

♦IMPLIED 

icc. 

CDATA 

♦IMPLIED 

alteqids 

CDATA 

♦IMPLIED 

qty 

NMTOKEN 

♦IMPLIED 

context 

%refids; 

♦IMPLIED> 

<! ELEMENT  consum 

-  o  EMPTY  > 

<! ATTLIST  consum 

%ids; 

milspec 

CDATA 

♦REQUIRED 

mfgcode 

CDATA 

♦REQUIRED 

govstd 

CDATA 

♦REQUIRED 

qty 

NMTOKEN 

♦REQUIRED 
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name- 

CDATA 

IIMPLIED 

type 

CDATA 

IIMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

nsn 

CDATA 

IIMPLIED 

cage 

CDATA 

IIMPLIED 

icc 

CDATA 

IIMPLIED 

uom 

CDATA 

IIMPLIED 

context 

%ref ids ; 

|IMPLIED> 

<! ELEMENT  verb  -  o  EMPTY  > 

< ! ATTLIST  verb  %ids; 

name  CDATA  I IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  IIMPLIED 

context  Irefids;  |IMPLIED> 

<! —  Deleted  verbsymb.  Name  is  enough.  — > 


<! ELEMENT  warning  -  o  EMPTY  > 

<1 ATTLIST  warning  %ids; 

text  %refid;  | REQUIRED 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  | IMPLIED 

xref  IDREFS  IIMPLIED 

context  %refids;  #IMPLIED> 


< I  ELEMENT  caution  -  o  EMPTY’  > 

<! ATTLIST  caution  %ids; 

text  %refid;  I REQUIRED 

name  CDATA  # IMPLIED 

type  CDATA  | IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  IIMPLIED 

context  %refids;  |IMPLIED> 


<! ELEMENT  note  -  o  EMPTY  > 

<i ATTLIST  note  %ids; 

text  %ref id;  I REQUIRED 

name  CDATA  # IMPLIED 

type  CDATA  IIMPLIED 

itemid  CDATA  IIMPLIED 

xref  IDREFS  IIMPLIED 

context  %refids;  |IMPLIED> 
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<! ELEMENT  annot  -  o  EMPTY  > 

< ! ATTLIST  annot  %ids; 

text  % ref id ;  # REQUIRED 

name  CDATA  # IMPLIED 

type  CDATA  ♦ IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  ♦IMPLIED 

user  CDATA  ♦ IMPLIED 

context  %refids?  #IMPLIED> 

< ; — ************************************************************ 

Parts  Information 

The  elements  "partinfo"  and  "partbase"  define  detailed  parts 
information.  "Partinfo"  describes  an  item  by  its  reference 
designator  ("refdes")  which  categorizes  parts  by  their  place  in  the 
system-subsystem  hierarchy.  "Partinfo"  describes  the  maintainer's 
view  of  the  part  information.  Each  "partinfo"  element  is  related 


to  a  "partbase"  which 

describes 

the  item  in  terms  of  its  part 

number  ("partnum") .  "Partbase"  describes  the  supply  system's  view 

of  the  part  information. 

Several  " 

'partinfo"  items  could  be  related 

to  the  same  "partbase." 

****************************************************************——> 

<! ELEMENT  partinfo  -  o 

EMPTY  > 

<! ATTLIST  partinfo 

%ids ; 

partbase 

IDREFS ’ 

♦REQUIRED 

refdes 

NMTOKEN 

♦REQUIRED 

unitsper 

NUTOKEN 

♦REQUIRED 

indxnum 

NUTOKEN 

♦REQUIRED 

mtbf 

CDATA 

♦REQUIRED 

graphic 

%ref ids; 

♦REQUIRED 

usablon 

NUTOKEN 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

nounid 

NUTOKEN 

♦IMPLIED 

nountype 

NUTOKEN 

♦IMPLIED 

replvl 

CDATA 

♦IMPLIED 

lru 

NUTOKEN 

♦IMPLIED 

context 

% re fids; 

♦IMPLIED> 

<! ELEMENT  partbase  -  o 

EMPTY  > 
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< ! ATTLIST  partbase 
partnum 
cage 
smr 
hci 
nsn 
name 
type 
itemid 
xref 
context 


%  ids  ; 
CDATA 

♦REQUIRED 

CDATA 

♦REQUIRED 

CDATA 

♦REQUIRED 

CDATA 

♦REQUIRED 

CDATA 

♦REQUIRED 

CDATA 

# IMPLIED 

CDATA 

♦IMPLIED 

CDATA 

♦IMPLIED 

IDREFS 

♦IMPLIED 

%refids; 

♦IMPLIED> 

<j— —***********************★**•********************★★*********** 

Fault  Information 

Three  types  of  fault  information  can  be  described  in  the  CDM:  (A) 
fault  reporting  decision  trees,  (B)  fault  isolation  decision  trees, 
and  (C)  dynamic  fault  isolation  models  (such  as  AFHRL's  MDAS 
model)  .  The  fault  reporting  and  isolation  decision  trees  are 
static,  predefined  decision  sequences.  A  dynamic  fault  model 
generates  the  decision  sequence  at  display  time  from  a  fault  model 
of  the  equipment.  In  the  case  of  a  decision  tree,  the  complete 
tree  is  defined  in  the  data.  In  the  case  of  a  dynamic  fault 
isolation  model,  only  the  data  needed  to  represent  the  fault  model 
of  the  equipment  is  defined  in  the  data. 

Any  of  these  diagnostic  data  structures  can  be  described  in  terms 
of  diagnostic  tests  (  "test”) ,  test  outcomes  ("outcome") ,  fault 
states  ("fltstate") ,  repairable  faults  (  "fault") ,  and  fault 
rectification  actions  ("rect") .  The  general  logic  is  that  you 
begin  a  fault  reporting  or  isolation  process  with  a  "test,"  which 
may  be  as  simple  as  "what  symptoms  did  you  observe?,"  or  as  a 
complex  as  a  50-step  checkout  procedure.  Each  "test"  will  have 
associated  "outcomes"  which  associate  possible  test  results  with 
new  fault  states  ("fltstate").  Test  results  are  described  as 
"precond"  statements  (e.g.,  voltage  =  4.5v.,  light  =  dim,  faultcode 
=  A123,  ...  )  which  are  asserted  by  the  "test"  procedure  as  the 
test  is  performed.  The  "outcome"  elements  relate  those  possible 
test  results  to  fault  states. 

A  "fltstate"  state  represents  a  node  in  a  fault  isolation  decision 
tree  or  a  set  of  plausible  faults  in  a  dynamic  fault  model  .  A 
"fltstate"  state  provides  the  information  necessary  to  select  the 
next  diagnostic  test.  In  a  decision  tree  the  test  is  explicitly 
identified  by  the  "test"  attribute  of  "fltstate."  In  a  dynamic 
fault  model,  the  "test"  is  not  explicitly  identified  (i.e.,  the 
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••test"  attribute  is  empty)  ,  and  the  "fltstate"  specifies  a  list  of 
implicated  faults  ("impfault")  and  a  list  of  exculpated  faults 
("expfault")  for  that  state.  Implicated  faults  are  those  which  are 
suspected  as  being  bad  in  the  fault  state.  Exculpated  faults  are 
those  known  to  be  good  in  the  fault  state.  These  fault  lists  are 
then  used  by  dynamic  software  to  generate  a  list  of  appropriate 
"tests"  which  will  further  isolate  the  list  of  implicated  faults. 
No  matter  how  the  test  is  selected,  statically  by  the  data  or 
dynamically  by  the  software,  the  selected  "test"  is  performed  and 
the  process  continues  until  a  fault  is  isolated.  In  a  decision 
tree  a  fault  is  identified  when  you  reach  a  final  "fltstate"  node 
which  does  not  reference  a  "test,"  but  lists  the  identified 
"fault."  In  a  dynamic  fault  model,  the  final  fault  is  identified 
by  the  software  and  is  not  explicitly  represented  in  the  "fltstate" 
element. 

Once  a  "fault"  is  identified,  the  rectification  (i.e,  repair) 
procedure  ("rect")  associated  with  the  "fault"  is  performed. 
Rectification  actions  also  have  an  associate  "test"  which  is 
generally  a  checkout  task  to  verify  that  the  rectification  action 
successfully  fixed  the  problem.  The  "rect"  element  also  has  a 
fault  attribute  which  is  a  list  of  faults  that  identifies  all  of 
the  faults  repaired  by  the  rectification  action. 

Tests  and  rectifications  can  be  performed  by  a  human  or  machine 
agent.  The  elements  "test"  and  "rect"  have  an  "agent"  attribute 
which  states  whether  the  action  is  performed  by  a  human  or  a 
machine. 

**************************************************************** — > 


<! ELEMENT  faultinf 
<i ATTLIST  faultinf 
test 
fault 
name 
type 
itemid 
xref 
context 


o  EMPTY  > 


%  ids ; 
%refids; 

IREQUIRED 

%refids; 

# REQUIRED 

CDATA 

# IMPLIED 

CDATA 

IIMPLIED 

CDATA 

# IMPLIED 

IDREFS 

#IMPLIED 

%refids; 

#IMPLIED> 

<i —  Deleted  faultrep,  faultiso,  and  faultmodel,  these  can  be 
represented  in  "type"  — > 


<! ELEMENT  test  -  o  EMPTY  > 

<! ATTLIST  test  %ids; 

task  %refids;  # REQUIRED 
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outcome 

%ref ids ; 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

text 

%refid; 

♦IMPLIED 

agent 

(  human  | 

machine  )  ’’human 

range 

CDATA 

♦IMPLIED 

context 

%ref ids ; 

♦IMPLIED> 

<! ELEMENT  outcome 
<! ATTLIST  outcome 

-  o  EMPTY  > 

lids ; 

precond 

IDREFS 

♦REQUIRED 

f ltstate 

Iref ids ; 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

text 

Iref id; 

♦IMPLIED 

context 

Iref ids ; 

#IMPLIED> 

<! ELEMENT  f ltstate 
<! ATTLIST  f ltstate 

-  o  EMPTY  > 

1  ids ; 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

text 

Irefid; 

♦IMPLIED 

expfault 

Iref ids; 

♦IMPLIED 

impfault 

Iref ids; 

♦IMPLIED 

weight 

NUTOKENS 

♦IMPLIED 

test 

Irefid; 

♦IMPLIED 

context 

Iref ids ; 

♦IMPLIED> 

<! ELEMENT 
< ! ATTLIST 


fault  -  o  EMPTY  > 


fault 

lids; 

rect 

Iref ids; 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

mtbf 

CDATA 

♦IMPLIED 

fault 

Ire fids; 

♦IMPLIED 

text 

Irefid; 

♦IMPLIED 

partinfo 

Ire fids; 

♦IMPLIED 

context 

Iref ids; 

♦IMPLIED> 

E-13 


Draft  Content  Data  Model 


Version  5.2 


5/29/90 


<! ELEMENT  rect  -  o 

EMPTY  > 

<! ATTLIST  rect 

%ids ; 

task 

% ref ids; 

IREQUIRED 

name 

CDATA 

I IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

I IMPLIED 

xref 

IDREFS 

# IMPLIED 

action 

(  swap  | 

maint  )  "swap" 

agent 

(  human 

|  machine  )  "human 

text 

%refid; 

IIMPLIED 

test 

%refids; 

IIMPLIED 

fault 

%ref ids ; 

IIMPLIED 

context 

%ref ids ; 

|IMPLIED> 

<1—  —  *******************************•»********+■***■)■**  +  ************* 
Text  Elements 

"Text"  is  the  primitive  text  element  referenced  by  more  complex 
data  elements  in  the  CDM.  A  "text"  unit  is  basically  a  text  string 
of  "parsable  character  data"  or  PCDATA.  Within  a  text  string, 
attribute  values  ("attvalue")  of  other  CDM  elements  may  be 
referer-ed  and  inserted  as  text  string.  For  example,  the  string 
may  contain  a  reference  to  a  standard  system  name,  or  a  standard 
part  nomenclature,  or  a  standard  task  name.  "Attvalue"  may  be  used 
to  embed  one  of  these  references  in  string  which  tells  the  display 
system  to  find  the  value  of  the  referenced  attribute  and  place  that 
value  into  the  text  string  for  display.  By  using  this  mechanism, 
standard  terminology  can  be  referenced  consistently  throughout  the 
data  base,  and  any  changes  to  the  standard  terminology  can  be  made 
in  one  location  and  automatically  updated  throughout  the  data  base. 


***************************  ************************************ — > 


<! ELEMENT  text  - 
< ! ATTLIST  text 
name 
type 
itemid 
xref 
context 


(  I PCDATA  |  attvalue) +  > 
%ids; 

CDATA  # IMPLIED 

(TEXT  |  TITLE)  #IMPLIED 
CDATA  # IMPLIED 

IDREFS  # IMPLIED 

%refids;  #IMPLIED> 


<! ELEMENT  title 
<! ATTLIST  title 
name 


-  -  (  IPCDATA  |  attvalue  )  +  > 

%ids; 

CDATA  | IMPLIED 
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< ! ELEMENT 
< ! ATTLIST 


< ! ELEMENT 
<! ATTLIST 


type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

IIMPLIED 

context 

%ref ids ; 

#IMPLIED> 

dictitem 

-  o  EMPTY 

> 

dictitem 

%ids; 

name 

CDATA 

IREQUIRED 

def 

%ref ids 

IREQUIRED 

type  (  gloss  |  abbsym  |  symbol  |  other 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

context 

% re fids ; 

|IMPLIED> 

attvalue 

-  O  EMPTY 

> 

attvalue 

elmntref 

%ref id;  IREQUIRED 

attname 

NAME  "name 

•« 

context  : 

% re fids  ? 

|IMPLIED> 

"other" 


<! — ************************************************************* 

Element  Cross  References 

The  element  "xref"  defines  a  cross  reference  or  relational  link. 
Each  cross  reference  has  at  least  one  %refid  which  may  be  an 
internal  reference  (pointing  to  an  element  within  a  particular  CDM 
data  base)  or  an  external  reference  (pointing  to  an  element  outside 
of  the  CDM) .  Internal  references  are  represented  by  "elmntref " 
which  is  a  reference  id  for  any  CDM  element.  External  references 
are  represented  by  "exrefid"  which  is  character  data  describing 
another  file  or  data  base  element.  All  cross  references  may  have 
a  type  ("relation")  which  is  a  text  string  describing  the  nature 
of  the  reference  (e.g.,  "theory,"  "IPB,"  "schematic").  There  is 
an  optional  attribute  "attname"  which  may  be  used  to  narrow  the 
"xref"  to  a  particular  attribute  value  of  the  cross-referenced 
element. 

************************************************************ — > 


< ! ELEMENT 
<! ATTLIST 


xref  -  o 
xref  id 
relation 
elmntref 
attname 


EMPTY  > 
ID 

CDATA 

%refids; 

NAMES 


IREQUIRED 
# IMPLIED 
# IMPLIED 
# IMPLIED 
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exrefid  CDATA  # IMPLIED 

context  %refids;  #IMPLIED> 


< I - *****************************************************'  » * i *  * 

Tables  and  Lists 

"Table,"  "colhddef,"  and  "entry"  define  the  structure  for  a  table 
of 

information.  The  cells  or  "entries"  of  a  table  may  be  a  "text" 
unit 

or  any  element  identified  by  an  "refid." 

A  "list"  is  a  general  purpose  structure  used  to  group  individual 
elements  into  a  list  of  elements  which  share  a  common  EMPTY  For 
example,  if  you  wanted  to  specify  that  a  list  of  steps  were  all  to 
be  performed  if  a  certain  precondition  were  true,  you  could  group 
those  steps  into  a  list  with  a  single  EMPTYwhich  specified  the 
desired  precondition. 

************************************************************* — > 


<! ELEMENT  table 

-  EMPTY  > 

< 1 ATTLIST  table 

%ids; 

colhddef 

IDREFS 

#REQUIRED 

entry 

IDREFS 

♦REQUIRED 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

# IMPLIED 

context 

%ref ids ; 

#IMPLIED> 

< ! ELEMENT 

colhddef 

-  o  EMPTY> 

<! ATTLIST 

colhddef 

id  ID 

♦REQUIRED 

colnum 

NUTOKEN 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

context 

%ref ids ; 

♦IMPLIED> 

< i ELEMENT 

entry 

-  o  EMPTY > 

< ! ATTLIST 

entry 

id  ID 

♦REQUIRED 

col 

NUTOKEN 

♦REQUIRED 

row 

NUTOKEN 

♦REQUIRED 

text 

%ref id; 

♦IMPLIED 

elmntref 

%ref id; 

♦IMPLIED 

context 

%refids; 

♦IMPLIED> 
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<! ELEMENT  list  -  O  EMPTY  > 

< ! ATTLIST  list  %ids ; 

elmntref  %refids;  # REQUIRED 
context  %refids;  #IMPLIED> 


<j  ——*******************************************★******************* 


Graphics 

The  CDM  allows  graphics  to  be  referenced  from  external  graphics 
files  or  embedded  in  the  CDM  data  base.  The  element  "grphprim"  may 
contain  a  "file"  name  which  identifies  an  external  file  containing 
a  graphic  data  in  any  of  the  enumerated  formats  (cgm,  iges,  dxf, 
fax,  ...  ) .  The  same  graphic  data  may  also  be  included  directly 
in  the  CDM  by  putting  the  data  in  the  "# PCDATA  "  content  portion 
of  a  "grphprim"  element. 

Both  "graphic"  and  "graphprim"  have  a  set  of  optional  attributes 
to  specify  transformations  (i.e.,  scaling,  translating,  rotating, 
clipping,  etc.).  A  "graphic"  or  "grphrim"  element  may  specify  a 
transformation  matrix  ( "transfrm") ,  a  clipping  "window,"  a  pen 
shape  ("penshape") ,  a  pen  pattern  ("penpatt") ,  and  a  label 
("text") .  Transformations  ("transfrm")  are  specified  by  a  9-number 
transformation  matrix  which  specifies  coordinate  translation, 
scaling,  reflection,  and  rotation  in  terms  of  homogeneous 
coordinates  (see  Chapter  3  of  Rodgers,  D.F.,  and  Adams,  J.A. , 
"Mathematical  Elements  For  Computer  Graphics,"  McGraw  Hill,  1976, 
for  a  complete  definition  of  this  matrix) . 

Composite  graphics  may  be  constructed  by  grouping  transformed 
graphics  ("graphic"  or  "grphprim")  into  a  "graphic"  element. 

These  transformed,  labelled,  named,  and  typed  graphic  illustrations 
are  then  referenced  by  steps  and  para  tags  in  the  CDM.  A 
composite  "graphic"  may  also  specify  a  list  of  "focus"  objects 
which  are  the  subgraphics  of  interest  in  that  particular 
illustrations.  This  attribute  could  be  used  to  specify  which 
subgraphics  in  an  illustration  are  to  be  highlighted,  labelled, 
etc.,  by  the  presentation  software. 

"Graphic"  and  "grphprim"  also  may  specify  a  minimum  size 
("minsize")  required  to  satisfactorily  display  the  graphic  to  the 
user.  The  minimum  size  is  specified  in  terms  of  the  amount  of 
visual  angle  the  graphic  image  should  subtend  on  the  eye.  This 
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will  allow  different  display  systems  with  different  viewing 
distances  to  adjust  the  physical  size  of  the  graphic  to  provide  the 
correct  visual  image  as  intended  by  the  author. 

*** *******  **************** ********************* ************** ***--> 


<1  ELEMENT  graphic 

-  o  EMPTY 

> 

<! ATTLIST  graphic 

%ids  ; 

graphic 

%refids ; 

IREQUIRED 

name 

CDATA 

IIMPLIED 

type  (  normal  |  locat 

overlap 

schem  1  functblk 

wiring 

engin  ) 

IIMPLIED 

itemid 

CDATA 

IIMPLIED 

xref 

IDREFS 

IIMPLIED 

text 

%refid; 

IIMPLIED 

focus 

% re fids; 

IIMPLIED 

transfrm 

NUTOKENS 

IIMPLIED 

window 

NUTOKENS 

IIMPLIED 

penshape 

CDATA 

IIMPLIED 

penpatt 

CDATA 

IIMPLIED 

minsize 

NUTOKENS 

IIMPLIED 

context 

%refids; 

|IMPLIED> 

< ! —  tgraphic  was  deleted  and  incorporated  into  graphic  — > 


<! ELEMENT  grphprim  -  (  # PCDATA  )> 

<1 ATTLIST  grphprim  %ids; 

name  CDATA  # IMPLIED 


type  (  normal  |  locat  overlay 

schem  |  functblk  wiring  | 

engin  )  IIMPLIED 


itemid 
xref 
text 
file 
coding 


CDATA 

IDREFS 

%refid; 

CDATA 


#IMPLIED 

IIMPLIED 

IIMPLIED 

IIMPLIED 


(cgmchar  |  cgmbin  |  cgmclear 
fax  |  iges  |  dxf  |  gks)  "cgmbin" 


transfrm 

window 

penshape 

penpatt 

minsize 

start 

stop 

context 


NUTOKENS 

NUTOKENS 

CDATA 

CDATA 

NUTOKENS 

NUTOKEN 

NUTOKEN 

%refids; 


IIMPLIED 

IIMPLIED 

IIMPLIED 

IIMPLIED 

IIMPLIED 

IIMPLIED 

IIMPLIED 

|IMPLIED> 
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——*************************************************************** 


Audio  -  Video  -  Process 

The  elements  "audio,"  "video,"  and  "process"  are  references  to 
either  a  file  name  or  an  external  source  which  contains  an  audio 
sequence,  a  video  sequence,  or  a  software  process,  respectively. 

*********************************************************** — > 


<! ELEMENT  audio 
< ! ATTLIST  audio 

-  o 
%ids ; 

EMPTY  > 

name 

CDATA 

K IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

file 

CDATA 

# IMPLIED 

exrefid 

CDATA 

# IMPLIED 

context 

%refids; 

#IMPLIED> 

<! ELEMENT  video 

-  o  EMPTY  > 

<! ATTLIST  video 

%  ids ; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

file 

CDATA 

# IMPLIED 

exrefid 

CDATA 

# IMPLIED 

context 

Irefids ; 

#IMPLIED> 

< ! ELEMENT  process 
<! ATTLIST  process 

-  o 
%ids; 

EMPTY  > 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

# IMPLIED 

xref 

IDREFS 

# IMPLIED 

file 

CDATA 

# IMPLIED 

exrefid 

CDATA 

# IMPLIED 

context 

%refids; 

#IMPLIED> 

<;—************************************************************* 
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Prompts 

A  ’'prompt"  specifies  either  a  f ill-in-the-blank  ("fillin’’)  or  menu 
choice  ("menu")  question  for  the  user.  Prompts  are  characterized 
in  terms  of  property-value  pairs  (like  assertions  and 
preconditions) .  Basically,  each  prompt  is  associated  with  a 
"property"  which  specifies  the  property  which  will  be  asserted 
along  with  the  user's  response  when  the  prompt  is  answered. 

If  the  prompt  is  a  "fillin’’  the  user's  response  will  be  asserted 
as  the  "value"  of  the  specified  "property".  If  the  prompt  is  a 
"menu,"  the  user's  "choice"  selection  from  the  menu  will  have  an 
associated  "value"  which  will  be  asserted  as  the  "value"  of  the 
prompt's  "property".  Once  this  assertion  is  made,  other  elements 
in  the  system  may  use  the  information  to  test  preconditions 
("precond")  concerning  the  asserted  property. 

The  "text"  of  a  prompt  is  the  question  which  will  be  displayed  to 
the  user.  The  "text"  of  a  "choice"  is  the  menu  choice  which  will 
be  displayed  to  the  user  as  his  list  of  possible  menu  selections. 


Both  "fillin’’  and  "menu"  prompts  can  have  a  "default"  value.  In 
the  case  of  a  "fillin,"  the  "default"  is  a  text  string  ( "CDATA" ) 
which  will  used  as  the  initial  entry  in  the  fill-in-the-blank  form. 
In  the  case  of  a  "menu,"  the  default  will  be  an  IDREF(S)  to  one  of 
the  possible  "choice"  responses. 

* *******  ******  *************  ****** ****** ***** ****** ******* ***——> 


< ! ELEMENT 

prompt 

-  o  EMPTY  > 

< ! ATTLIST 

prompt 

%ids; 

name 

CDATA 

# IMPLIED 

type 

CDATA 

# IMPLIED 

itemid 

CDATA 

♦IMPLIED 

xref 

IDREFS 

♦IMPLIED 

text 

%ref id; 

♦IMPLIED 

fillin 

%refids; 

♦IMPLIED 

menu 

% re fids; 

♦IMPLIED 

context 

%refids; 

♦IMPLIED> 

< ! ELEMENT 

fillin 

-  o  EMPTY  > 

<1 ATTLIST 

fillin 

%ids; 

property 

IDREF 

♦REQUIRED 

text 

%refid; 

♦REQUIRED 

name 

CDATA 

♦IMPLIED 

type 

CDATA 

♦IMPLIED 

itemid 

CDATA 

♦IMPLIED 
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xref  IDREFS  #  IMPLIED 

range  CDATA  # IMPLIED 

default  CDATA  # IMPLIED 

context  %refids;  #IMPLIED> 


<! ELEMENT  menu  -  o  EMPTY  > 

< ! ATTLIST  menu  %ids; 

text  %ref id;  # REQUIRED 

property  IDREF  # REQUIRED 

choice  IDREFS  # REQUIRED 

name  CDATA  # IMPLIED 

type  CDATA  # IMPLIED 

itemid  CDATA  # IMPLIED 

xref  IDREFS  #IMPLIED 

select  (  single  |  multiple  )  "single" 

default  IDREFS  #IMPLIED 

context  %refids;  #IMPLIED> 


<! ELEMENT  choice  -  o  EMPTY  > 

<! ATTLIST  choice  id  ID  # REQUIRED 

text  %ref id;  # REQUIRED 

value  IDREFS  IREQUIRED 

context  %refids;  #IMPLIED> 


< i— — ************************************************************* 
Context  and  Assertions 

Every  CDM  composite  object  also  has  EMPTY  Vehicle  configuration, 
security  level,  and  technician  skill  level  are  examples  of  context 
properties  which  determine  the  applicability  of  a  particular  data 
element  to  the  situation  at  hand.  "Context"  consists  of  a  set  of 
frequently  used  "ef fectivity"  attributes  (security,  config,  track, 
version)  ,  and  a  list  of  user-defined  "precond"  (preconditions  ) . 


"Precond"  and  "assertion"  are  both  defined  in  terms  of 
property-value  pairs.  A  "property"  is  any  "text"  string  which 
defines  a  property.  A  "value"  is  another  "text"  string  defining  the 
value.  Property-value  pairs  may  be  asserted  or  tested  by  the 
run-time  presentation  software.  An  "assertion"  on  a  para  tag  or 
step  will  be  asserted  whenever  that  para  tag  or  step  is  performed . 
A  "precond"  is  a  test  of  a  property  previously  asserted.  The 
property  element  also  has  an  "elmntref"  attribute  which 
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is  an  optional. attribute  which  may  be  used  to  indicate  a  prompt  or 
task  which  can  be  activated  to  acquire  a  value  for  the  property  if 
none  has  been  asserted. 

dr**************************************************************  —  —  > 

<! ELEMENT  context  -o  EMPTY  > 

< ! ATTLIST  context  id  ID  # REQUIRED 

security  (uc  |  c  |  s  |  ts)  #IMPLIED 
restrict  NMTOKENS  # IMPLIED 
release  NMTOKENS  # IMPLIED 
codeword  NMTOKENS  # IMPLIED 
scilevel  NUMBER  #IMPLIED 
diglyph  NMTOKENS  # IMPLIED 
config  NMTOKENS  #IMPLIED 
maintlvl  CDATA  # IMPLIED 

track  NUTOKENS  # IMPLIED 

version  NUTOKENS  #IMPLIED 
valstat  CDATA  #IMPLIED 

verstat  CDATA  # IMPLIED 
precond  IDREFS  # IMPLIED 
context  %refids;  #IMPLIED> 


<! ELEMENT  assertion  -  o  EMPTY  > 

<! ATTLIST  assertion  id  ID  # REQUIRED 

property  IDREF  IREQUIRED 

value  IDREFS  # REQUIRED 

context  %refids;  #IMPLIED> 


<! ELEMENT  precond  -  O  EMPTY  > 

<! ATTLIST  precond  id  ID  # REQUIRED 

property  IDREF  # REQUIRED 

value  IDREFS  # REQUIRED 

polarity  (  pos  |  neg  )  "pos" 
op  (  eq  |  It  |  lte  |  gt  |  gte  |  in  )  "eq" 
context  %refids;  #IMPLIED> 

<! ELEMENT  property  -  o  EMPTY  > 

<! ATTLIST  property  id  ID  IREQUIRED 

text  %ref id;  # REQUIRED 

elmntref  %refid;  # IMPLIED 

context  %refids;  #IMPLIED> 

<! ELEMENT  value  -  o  EMPTY  > 

<! ATTLIST  value  id  ID  # REQUIRED 

text  %refid;  IREQUIRED 

context  %ref ids;  #IMPLIED> 
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Copies 


Copies 


3  OASD  (P&L) 

1  B.Lepisto 
1  M.  McGrath 
1  M.  Meth 

5  DQSO 

J.  Winters 

6  DSPO 

5  J.  Dalgety 
1  W.  Gorham 

1  HQAMC 
M.  Ducody 

5  AMC-PM-TMDE 
Pat  Stevens 


1  Smithsonian  Insti¬ 
tution 

W.  Sinaiko 

8  CNO 

1  OP-1 1 1 J2  J.  Hart 
1  OP-403  CAPT  Hicks 
5  OP-403  S.  Brookins 
1  OP-46  P.  Cataldo 

1  ONT-22 

LCDR  A.  Baivier 

3  SPAWAR 

1  003-221  B.  Ellis 
1  PMW-153 
1  PMW-164  P.  Davenport 


1  CMDCECOM 
J.  Rogowski 

1  Army  Materiel 
Readiness  Support 
Activity 

A.  Rulon 

5  AFHRL  (LRC) 

D.  Gunning 

6  AFLC 

5  MMD  S.  Holloway 
1  LMSC/SJT  J.  Smith 

1  ASD/YFL 
D.  Mates 

1  NIST 

D.  Bettwy 


9  NAVAIR 

1  AIR— 41032  P.  Dolan 

1  AIR-4 1122F  K.  Brookins 
5  AIR-4114  S.Magill 

2  PMA-235  CDR  D.  Williams 

10  NAVSEA 

1  SEA-04-TD  H.  Felsen 
1  SEA-04-PA  R.DiGeronimo 
1  PMS-350  M.  Volpe 
1  PMS-393 

1  PMS-396  CDR  N.  Messenger 
1  PMS-400  CDR  R.  Acree 
1  PMS—409  G.  Williams 
1  PMS-413 
1  PMS-418  G.  Shaffer 
1  SEA-92X  G.  Rogers 
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INITIAL  DISTRIBUTION  (Continued) 


Copies  Copies 


2 

NAVSUP 

1 

NPRDC 

PML-550  D.  Kyle 

W.  Wulfeck 

SUP-0323A1  J.  DeTolla 

1 

Naval  Postgraduate 

1 

NAVFAC 

School  Library 

09M13  R.  Silverman 

1 

AEGIS  Training  Center 

1 

CMC  PSD-M3 

L.  Miller 

1 

NOSL/Louisville 

1 

NSWSES 

J.  Shea 

R.  Piepenbrink 

2 

NESEC-750  Portsmouth 

1 

NESEA 

W.  Chiaiese 

N.  Medved 

1 

NSDSA  5H10 

12 

DTTC 

W.  Honea 

1 

Batelle  Wash.,  Ops. 

5 

NATSF 

C.  Oates 

3  0128  G.  Gruden 

1 

Boeing  Commercial 

1  012  W.  Smith 

Airplane  Company 

1  01  A.  Teretsky 

J.  Anderson 

1 

NPPSMO— 41 

1 

Boeing  Military 

J.  Karpovich 

M.  Post 

1 

NPFC-100 

1 

CDC 

LCDR  P.  Jensen 

F.  Tittle 

1 

NOSC 

1 

EER  Systems 

R.  Smillie 

N.  Bukowski 

1 

NUSC 

1 

EG&G 

A.  Valm 

L.  Snodgrass 

2 

NTSC 

1 

General  Dynamics 

W.  Rizzo 

Electronic  Division 

H.  Thorstad 

D.  George 
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INITIAL  DISTRIBUTION  (Continued) 


Copies 

1  General  Dynamics 

Electric  Boat/459 

L.  Miller 

6  General  Dynamics 

Ft.  Worth,  TX 
1  B.  Dimock 
5  J.  Fleming 


Copies 

3  RJO 

R.  Huckaby 

2  Scientific  Manage¬ 

ment  Associates 

1  S.  Rainey 
1  T.  Post 

1  TRW 


1  General  Electric, 

Lynn 

J.  Tilton 

1  Grumman  Aircraft 

M.  Plawsky 


M.  Thompson 

2  Westinghouse 
1  R.  Tyree 
1  J.  Coviello 

CENTER  DISTRIBUTION 


1 

IBM,  Rockville 

Copies 

Code 

Name 

J.  Manthe 

1 

00 

CAPT  C.  Graham 

1 

INET 

1 

01 

R.  Metrey 

R.  Richards 

1 

12 

G.KeiT 

1 

LMI 

1 

1807 

K.  Stabenau 

J.  Giles 

1 

182 

A.  Camara 

1 

McDonnell  Aircraft 

20 

182.3 

J.  Fuller 

1  R.  Jackson 

1 

182.3 

R.  LeBeau 

1  M.  McCormick 

1 

182.3 

E.  Jorgensen 

1 

Newport  News 

1 

1821 

J.  Junod 

Shipbuilding 

1 

1826 

J.  Gamer 

J.  Meredith 

1 

185 

R.  Schaffran 

1 

Northrup 

1 

187 

R.  Ploe 

J.  Bean 

1 

3411 

C.  Naas 
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INITIAL  DISTRIBUTION  (Continued) 


Copies  Code  Name 

1  342.1  (C) 

1  342.2  (A) 

10  3432  Reports  Control 
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